Skip to content

Standard Library

The Zynx standard library provides the core modules for ownership-aware data types, I/O, platform access, async work, data formats, and low-level runtime integration.

Use this page to choose a module. Use the complete inventory when you need module stability labels, exports, re-exports, or internal implementation modules.

Stability

  • mvp: current public module. Normal source may import this module under the documented contract.
  • internal: implementation support for stdlib/compiler code. The compiler rejects imports outside the owning implementation subtree; these modules are not user API.
  • experimental: reserved for modules shipped behind an explicit experimental boundary. No current lib/std module is experimental.

Removed modules:

  • std.task: removed from the source and SDK surface. Use std.async.

Accepted crypto migration:

  • The target std boundary retains only std.crypto.random.fill and std.mem.wipe; algorithms move to the exact-revision external zynx-crypto package. See the cryptographic boundary. The current inventory remains transitional until that migration is implemented.

Accepted filesystem-capability migration:

  • Portable safe Zynx has no live process-global CWD read or mutation. RFC 0022 removes the current env.cwd/chdir, process.cwd/chdir, and fs.cwd experiments. RFC 0023 fixes the successor: lossless Path, checked RelativePath and AbsolutePath refinements, filesystem work anchored in an explicit Dir capability, and the child-only WorkingDirectory.Start | Path(^fs.AbsolutePath) process policy. RFC 0066 injects initial Dir and net.Network authority only through private executable-root @host let name: Type in _; loans and removes fs.open_root, MissingRoot, registries, defaults, and string lookup. RFC 0068 fulfills those requirements only through an explicitly supplied per-instance zynx-launch grant plan; actual grants never enter package metadata, argv or environment, and process_start is an explicit directory source rather than a magic binding name. RFC 0069 completes that plan with mandatory closed allow-only policies: exact operation rights for Dir, exact raw-name resolution policy, and independent numeric endpoint rules for TCP and UDP. Empty explicit policy denies; omission is invalid; derived authority never widens. RFC 0070 adds exactly capability-relative one-final-entry directory creation, exact-kind removal, and replace-capable dual-Dir rename. Their cold std.async.fs counterparts return Futures without function coloring; cross-filesystem rename is IOError.CrossDevice, never an implicit copy. zynx-launch v2 adds only five named directory rights and copies v1 plus the complete Network schema unchanged. RFC 0071 closes the file-open state space with explicit FileAccess and OpenDisposition axes inside OpenMode. Its five dispositions distinguish existing-only, open-or-create, atomic create-new, truncate-existing, and create-or-truncate behavior. All fifteen combinations are valid and map to the four already accepted file-open rights before lookup; no launch version or right is added. The target has no .Read shorthand, Boolean open flags, defaults, builder, bitmask, or append mode. RFC 0072 adds only explicit full-integrity File.sync and namespace Dir.sync barriers plus cold std.async.fs counterparts. zynx-launch v3 appends independent open_file.sync and sync_directory rights while freezing v1/v2 and Network; an unrepresentable barrier fails launch rather than becoming a no-op. IOError.Unsupported = 18 covers inability discovered only from a concrete mounted resource. Core std still has no durability flag, implicit sync-on-drop, write_atomic, or publish_file target helper. RFC 0073 adds append as a separate nominal capability: AppendAccess and AppendMode open blocking or asynchronous AppendFile owners whose write performs one possibly short, indivisible EOF append. Append has no caller offset, hidden write_all, or OpenMode/FileAccess alias; ReadAppend reads the same identity through explicit read_at, and sync remains an independently granted barrier. zynx-launch v4 copies v3 and adds only open_file.append; targets without certified atomic EOF placement fail closed rather than emulate it with size plus offset write. RFC 0074 closes durable single-file publication without adding a target owner, helper, error, right, or zynx-launch v5. There is no Publication, StagedFile, PreparedFile, write_atomic, generated staging-name policy, cleanup-on-drop, rollback, or universal recovery transaction. The sole portable recipe is caller-chosen same-parent CreateNew, an explicit short-write loop, File.sync, drop, path-based Dir.rename, and Dir.sync on the exact directory whose direct-child entry changed. A parent above that directory is not sufficient; external name coordination and recovery from ambiguous completed phases remain application policy. RFC 0067 narrows core DNS to one explicit dns.resolve(Network, host) which returns scope-preserving address data; service/reverse lookup, numeric-host fallback and automatic connection policy remain outside core std. RFC 0025 adds capability-anchored traversal through concrete fallible lending Dir.entries() and Dir.walk() cursors. Entries lend RelativePath views and require explicit clone() for retention; traversal is depth-first, non-following and terminal on error. Free walk(str), glob and matches are deleted from target core std without aliases. RFC 0063 makes std.fs explicitly blocking and adds nominally distinct std.async.fs.File for cooperative-safe access. Both file types use explicit u64 offsets and possibly-short read_at/write_at; neither has a hidden cursor or direct stream interface. The target has no ambient/whole-file helpers, exists, read_text, implicit cross-filesystem move fallback, or async traversal. async.blocking is the sole general bridge for deliberately coarse blocking work, and cancellation waits for true completion rather than detaching it. The current source inventory remains transitional until that migration is implemented.

Accepted exact mutation vocabulary:

  • RFC 0064 gives public target std mutation verbs one meaning each: sequence tail push, text-suffix append, positional insert, map association put, non-positional membership add, end removal pop, selected remove, resource-retaining clear, and same-kind owner-transfer merge.
  • Collection append/extend, delete/erase/take, remove_entry, map/set insert, put_all, and add_all are absent without aliases. The rule does not rename domain operations such as iter.take, MaybeUninit.take, arithmetic add, filesystem remove, or stream write, and it does not reserve words in user code. Retained JSON put/push names are classified without ratifying the complete mutable-DOM semantics. See the naming policy.

Accepted process-environment migration:

  • Portable safe Zynx exposes one immutable, lossless process-start environment through std.env.variables(). It has no live get, set, or remove. Child options choose either that exact start snapshot or a validated complete replacement; spawning never implicitly rereads the native process-global environment. The current source inventory remains transitional until RFC 0024 is implemented. See std.env and std.process.

Accepted owner-anchored raw-view migration:

  • RFC 0053 replaces the false-owner std.mem.slice(ptr, length) experiment with exactly one overloaded unsafe name, std.mem.view(ptr, length, anchor). An ordinary final anchor returns shared [T] in L; explicit &anchor returns exclusive &[T] in L. Both require fully initialized provenance-correct storage and keep the real source borrowed for the result's region. The API never creates an owning slice or exposes uninitialized capacity as [T]. See std.mem.

Accepted exact volatile-access migration:

  • RFC 0075 exposes only the ordinary unsafe SDK names std.mem.volatile.load and std.mem.volatile.store. Each has exactly eight non-generic overloads: i8, u8, i16, u16, i32, u32, i64, and u64. The public @zynx.volatile.read/write experiment is removed; any semantic primitive below the SDK remains compiler-private.
  • Every dynamically reached call maps to exactly one target-certified native same-width volatile access. Unsupported targets fail compilation rather than splitting, calling a helper, or emulating it. The caller must already hold valid aligned live provenance and authority; the API mints no mapping or MMIO capability. Volatile supplies no atomicity, synchronization, ordinary/atomic ordering, fence, cache/DMA maintenance, completion, endian, or device-protocol guarantee. See std.mem.

Accepted host-provided MMIO migration:

  • RFC 0076 adds exactly one nominal std.mmio.Region authority, injected as a private executable-root @host let name: mmio.Region in _; loan. The trusted host retains the exact bounded mapping through entry quiescence; user code cannot construct, duplicate, close, unmap, resize, discover, or project its pointer or address. The value is non-Copy, non-Clone, neither Send nor Sync, and every generic Wasm/WASI target rejects it.
  • Region exposes readonly size plus exactly eight fixed-width integer load_* and eight matching store_* methods. Each unsafe method checks its v5 grant, complete byte bounds, and natural alignment before device access. Failure is mmio.AccessError with zero accesses; success is exactly one same-width RFC 0075 volatile access. There are no generic/typed registers, pointers, subregions, RMW/bulk helpers, async surface, endian policy, fences, DMA/cache maintenance, completion, or device protocol. See std.mmio.

Accepted C-string boundary:

  • RFC 0059 adds one nominal std.ffi.CStr role family. CStr in L is a bounded immutable terminated-byte view, ^CStr is its exact owner, and c"..." creates static allocation-free values. RFC 0061 makes every dynamic str use checked allocating CStr(Bytes(text)); no text role projects a termination proof. Foreign storage first receives a real bound and anchor, then uses CStr.find. There is no CString, unbounded pointer constructor, mutable C string, implicit C ABI lowering, or Wasm-string conversion. See std.ffi.

Accepted append-only output migration:

  • RFC 0054 adds affine OutputSpan<T> as the sole safe session for initializing a bounded contiguous suffix of ^[T]. output(^self, additional) takes the owner; push grows the initialized prefix, and explicit commit or cancel returns the successor owner. Session overflow traps and unfinished-session drop destroys the complete collection.
  • Only the byte specialization exposes spare_ptr plus unsafe advance for foreign output. Sync readers retain initialized &[u8] overwrite and gain an output-span overload; async operations that can retain an output pointer own the span until true completion. The target removes ByteBuffer and does not use output spans for sparse arena or hash-table storage. See std.slice, std.io, and std.async.io.

Accepted sparse-container storage migration:

  • Arena<T> and the shared RawTable<E> behind HashMap and Set own sparse slots through an SDK-internal affine RawStorage<T>, never through a false owning slice. The raw owner is liveness-blind; dense arena occupancy or table control bytes remain the sole authoritative initialized-slot metadata.
  • RawTable uses one allocation containing its aligned slot prefix, padding, control bytes, and mirrored suffix. RawStorage has no public API, bitmap, slot-token family, checked hole-bearing view, or grow/realloc operation. Arena, HashMap, and Set use only the built-in allocation domain. The checked-in implementations remain transitional. See std.arena, std.collections, and std.mem.

Accepted single-slot initialization migration:

  • std.mem.MaybeUninit<T> stages exactly one value. Its role-directed .ptr yields *T from shared access and *mut T from explicit exclusive access, with no ptr_mut alias and no state change. Unsafe initialize performs a no-drop move into a proven empty slot, and unsafe take returns one owner from a proven complete valid slot. The wrapper stores no liveness tag and never drops a possible payload.
  • The target removes mem.write_at, read_at, and drop_at. It adds no raw allocation-to-range constructor, mem.view retyping of fresh allocation, range-wide publication/conversion, adoption, uninitialized-buffer API, ArrayBuilder, or generic raw output pointer. Explicit wrapper aggregates remain ordinary composition. OutputSpan<T> remains the contiguous-output protocol and RawStorage<T> remains private sparse-container machinery. General live-value cleanup suppression is absent: there is no ManuallyDrop<T>, forget, or leak API. Type-local discard self belongs to the language's nominal consuming-finalization semantics and still drops every residual field. The source inventory is transitional until this migration is implemented. See std.mem.

Accepted allocation-domain migration:

  • All ordinary owning standard-library values use one compiler/runtime-private built-in allocation domain per runtime instance. No allocator value, callback set, provider identity, constructor option, generic parameter, raw allocation function, or ambient replacement is public.
  • Checked allocation failure is std.mem.AllocError.OutOfMemory. The target removes the complete public std.allocator module without an alias or re-export. Empty and physically zero-sized storage performs no runtime allocation. Foreign, secret, mapped, pinned, device, and other semantically distinct storage remains in nominal resource types with matching cleanup; it cannot be adopted as a built-in owner.
  • The current source still carries allocator callbacks and the old error path during migration. The hidden historical page is not part of the target website or public module index. See std.mem.

Module Guide

AreaUseModules
Ownership, memory, and dataAllocation errors, arenas, byte views, strings, Unicode, native C strings, raw memory, explicit MMIO regions, and bit operations.std.mem, std.mmio, std.arena, std.bytes, std.strings, std.unicode, std.ffi, std.bit
Collections and valuesArrays, slices, maps, sets, iterators, arithmetic policies, float math, and durations.std.slice, std.collections, std.iter, std.arith, std.math, std.time
I/O and platformNominal sync and async I/O resources, blocking and cooperative-safe filesystems, environment snapshots, processes, capability-scoped networking, and CPU feature detection.std.io, std.async.io, std.fs and std.async.fs, std.env, std.process, std.net, std.cpu
Async and communicationFutures, tasks, groups, channels, and capability handles.std.async, std.channel, Capsule<T>
Shared memory and synchronizationLock-free atomics, mutual exclusion, and isolated per-OS-thread state. See the Concurrency guide.std.atomic, std.mutex, ThreadLocal<T>
Data formats and algorithmsJSON, text encodings, compression, non-cryptographic hashing, and the secure-random boundary. Cryptographic algorithms are external.std.json, std.encoding, std.compress, std.hash, cryptographic boundary

Module Pages

Each public module page documents purpose, ownership behavior, allocation behavior, error behavior, examples, and API details. Start with the module page for day-to-day use:

Complete Inventory

The complete inventory lists every shipped std module with its stability label, exported types, exported values, exported errors, and notes. It includes internal modules so maintainers can check source-tree drift.

Released under the MIT License.