Skip to content

Native-files-supported

Query whether the current backend provides real file support for file_sink(...) and related file runtime operations. This helper is the public capability gate for code that needs to decide whether host file logging is actually available on the current target.

Interface

moonbit
pub fn native_files_supported() -> Bool {}

output

  • Bool - true when the active backend provides real file support, otherwise false.

Explanation

Detailed rules explaining key parameters and behaviors

  • This helper is target-sensitive runtime capability detection, not a compile-time type gate.
  • The native backend currently returns true.
  • The stub backend used for non-file-capable targets currently returns false.
  • File APIs can remain part of the broader portable surface, but callers should use this check before depending on actual file creation, writes, flushes, or reopen behavior.

How to Use

Here are some specific examples provided.

When Need Safe Cross-target File Logging

When code should enable file output only on targets that really support it:

moonbit
if native_files_supported() {
  let sink = file_sink("app.log")
  Logger::new(sink).info("started")
}

In this example, file logging is activated only when the backend can actually provide it.

When Need To Match Runtime Availability Checks

When capability detection should align with file sink health state:

moonbit
let sink = file_sink("app.log")
inspect(sink.is_available() == native_files_supported(), content="true")

In this example, the public support flag matches the observable file sink availability contract.

Error Case

e.g.:

  • If this helper returns false, callers should not treat file writes, flushes, or reopen operations as available runtime behavior.

  • If this helper returns true, individual file operations can still fail later because of path, permission, or filesystem state issues.

Notes

  1. Use this helper as the first portability guard around file_sink(...), file(...), and file-runtime control APIs.

  2. See target-verification.md when you need the current local verification boundary for target-sensitive behavior.

Published from the repository docs folder with VitePress.