Dynamic Stdlib
The a-la-carte standard library design for granular and monolithic builds.
Why this model
La3 rejects a hard no_std split and instead treats the stdlib as a set of independent modules.
The target is one language that can fit both embedded and full-application use cases without forking the standard library into two worlds. The module granularity is the unit of independence, and the build only includes what the program actually reaches.
- Independent modules are the invariant.
- Only reachable code is present in the final artifact.
- When two modules coexist, one may opportunistically reuse the other's implementation.
Requirements
The design is pinned by a small set of normative requirements rather than loose preferences.
- Independence in the alone case.
- Usage-driven inclusion in the final binary.
- Behavioural identity between granular and monolithic builds.
- Deterministic provider selection for reproducibility.
Capabilities
Modules share through declared capabilities, not by reaching for each other's private internals.
A capability is the reusable contract: a named facility, its signature, its semantic rules, and the suite that proves implementations agree.
- Modules can want a capability and ship a private fallback.
- Providers can satisfy the capability for everyone else.
- Sharing only ever removes duplication that would otherwise exist.
Build modes
Granular mode optimizes for size; monolithic mode optimizes for throughput and convenience.
- Granular mode is what you want for Pico, kernels, and small embedded targets.
- Monolithic mode is the default and behaves identically, just with a different inclusion strategy.
- The docs should make the behavioral identity guarantee explicit every time the two profiles are mentioned.