LEARN VOID / TOOLING & INTEGRATION
Native integration
Bring existing libraries into the language through deliberate boundaries.
No standalone native-binding program is offered here: the supported subset requires an explicitly trusted embedding host and its supplied virtual module. Ordinary CLI execution does not authorize arbitrary C libraries. The guide below explains that boundary without presenting proposed binding syntax as runnable code.
The goal: native libraries that feel like VOID
The long-term direction is typed .void wrappers around C libraries, keeping raw pointers, buffer ownership and foreign string representations out of ordinary application code. The compiler and runtime should carry the difficult boundary rules.
What works today
The implemented subset is an explicitly trusted, statically linked C fixture provided by an embedding host. Its typed descriptor supplies a virtual native_bridge module; ordinary wrappers use managed resource identities, exact-width scalar types, owned UTF-8 transfers and rooted callbacks.
What is still ahead
This is not general-purpose native loading. There is no public arbitrary-library declaration syntax, dynamic loader or package resolver. Ordinary CLI and editor sessions do not automatically authorize native fixture imports. Resource ownership, callback lifetime and thread restrictions remain part of the binding contract.
Resources still need a lifetime
Garbage collection does not close a native resource. The scoped cleanup guide explains deterministic ownership. Wrappers use explicit release or deterministic deinit/with cleanup. Native resource handles cannot be transferred to worker tasks.