Problem
The Wave standard library currently mixes raw operating-system primitives, descriptor helpers, and user-facing APIs. Names such as fs_open inside std::fs::file repeat module context, while functions such as fs_read_all expose caller-managed buffer contracts that are not obvious from their names.
The public boundary should be decided before broad API expansion.
Proposed layers
- std::sys: target-specific operating-system primitives and ABI contracts.
- std::io: descriptor, stream, buffering, and byte transport helpers.
- std::fs: user-facing file and directory operations.
- std::libc: explicit C library bindings, separate from direct system providers.
std::sys may contain source-auditable platform work before the compiler can execute that target. Unsupported targets must remain clearly gated and must not be advertised as runnable.
Decisions required
- Naming and prefix rules inside namespaced modules.
- Public re-export policy between sys, io, fs, net, process, and time.
- Path-based versus descriptor-based operation names.
- Error conventions before and after runtime variant lowering is available.
- Ownership rules for strings, buffers, handles, and allocated results.
- Compatibility and migration policy for pre-beta API changes.
Workstreams
Completion criteria
Problem
The Wave standard library currently mixes raw operating-system primitives, descriptor helpers, and user-facing APIs. Names such as fs_open inside std::fs::file repeat module context, while functions such as fs_read_all expose caller-managed buffer contracts that are not obvious from their names.
The public boundary should be decided before broad API expansion.
Proposed layers
std::sys may contain source-auditable platform work before the compiler can execute that target. Unsupported targets must remain clearly gated and must not be advertised as runnable.
Decisions required
Workstreams
Completion criteria