Dynamic Modules

Dynamic runtime loading remains experimental/internal and is not part of the normal 0.0.0-dev source language. Public code that needs modules should use import with source, interface, or static .zxm bundles.

The compiler/runtime still contain internal and interop-test support for runtime-loaded .zxm bundles, but normal source rejects require(...). Dynamic bundles also cannot be imported with import.

Use ordinary imports for public code:

import std.io;
import {
    String
} from std.string;

Static modules and package paths are resolved by the compiler before codegen. This gives the analyzer a fixed exported surface and keeps the build reproducible.

Imported modules expose only exported declarations. See Visibility and Privacy for export, from imports, aliases, re-exports, and generated .zxm interfaces.

require("module.zxm") is retained for internal dynamic-loading experiments and interop fixtures. It is not documented as a normal application API.

Experimental require failures use the builtin DynamicError error set, so internal interop fixtures use signatures such as:

fn invoke() throws(DynamicError) -> i32 {
    const module = try require("libexample.zxm");
    return try module.run();
}

Dynamic or unknown error sets can only be handled with wildcard catch arms because normal source cannot prove their concrete variant names.

• require(...) is rejected in normal source.
• Dynamic bundles cannot be imported with import.
• Ordinary source, interface, and static .zxm bundles cannot be loaded with experimental require.
• Dynamic exported generic functions, exported type values, and dynamic struct literals are not public APIs.

See Modules and ABI for the static module and ABI model.