Design status and open decisions¶
This is the first documentation edition, based on the language design baseline. It describes intended behavior and does not certify that a compiler or any individual feature has been implemented.
How to read this documentation¶
- Selected rules describe the design baseline.
- Provisional identifies syntax, names, or mechanisms that may change.
- Open identifies behavior that has not been settled.
- v0.1 boundary records an initial limit or a deferred capability.
Examples explain semantics; the complete grammar has not been frozen. Short
examples may omit setup or unrelated exception annotations. ... is a
placeholder for development examples, not a finished production implementation.
No installation procedure or executed Arbor example is claimed in this edition.
The reference covers the whole design baseline. Inclusion here does not imply availability in v0.1. The standard-library page likewise lists intended capabilities rather than invented import paths or signatures.
Unresolved specification work¶
The following areas need further specification. An example spelling does not resolve an open rule. The topic chapters preserve local qualifications alongside the selected semantics.
| Area | Still to settle |
|---|---|
| Compiler architecture | Bootstrap language, backend, initial OS/architecture, internal representations, artifact formats |
| Memory | Reclamation, cycles, lifetime notation/inference, moves/copies, thawing, resource freezing |
| Unsafe/FFI | ABI, pointer types, pinning, retained addresses, trusted wrapper contracts |
| Grammar | Final declaration, modifier, borrowing, decorator, boolean, sentinel, and choice spellings |
| Numeric semantics | Decimal division/precision, fraction literals, promotion, equality/hash, wrapping APIs, literal overload resolution |
| Modular values | Final type/API names and implementation of runtime moduli and inverse results |
| Strings | Representation, Unicode indexing, interpolation, normalization, detailed escapes, mutation operations |
| Temporal values | Precision/range, leap-second policy finalization, period arithmetic policies, geographic lookup scope |
| Containers | Homogeneous tuples, heterogeneous runtime indexing, slice ownership, empty accessors, equality/hash details |
| Classes | Shared ancestor storage, constructor/destructor order, field conflicts, default overrides, mixin/root interaction |
| Accessors | Lazy-cell effects, frozen-object eligibility, class cache ownership, setter signatures |
| Effects | Full throws grammar, built-in exceptions, generic effect checking, exceptional control events |
| Ellipsis | Runtime value behavior versus production unfinished-code rejection |
| Contracts | Predicate rules, metadata, proof reuse, blame diagnostics, runtime failure representation |
| Variance | Initial supported proofs and future checked capability annotations |
| Async | Scheduler, cancellation/cleanup, blocking bridges, promise ownership and failure representation |
| Caching | Eligibility, key snapshots, mutable results, eviction controls, context identity |
| Testing | Fixture teardown, patch implementation, mutable call snapshots, resource isolation, coverage details |
| Packaging | Local-label grammar, resolver details, registry/publishing protocols, source overrides, lockfile schema |
| Configuration | Supported YAML subset, schema implementation, bootstrap use of settings |
| Toolchain | Supported bundle format, compatibility protocol, exact submodule boundaries/remotes |
v0.1 boundaries¶
These are limits and priorities, not a promise that every other designed feature will ship in the first implementation:
- No 256-bit numeric types.
- No separate fixed-size array type.
- Full YAML can wait; manifest support cannot.
- Separate static accessors and borrowed-key containers are deferred.
- Advanced mutation/variance proofs can reject valid-but-unproved cases initially.
- Ordinary exact dependency pins precede any possible future range syntax.
- Code reuse through incremental compilation matters more than exceptionally fast clean builds.
- Tooling, testing, and diagnostics are part of the product, not optional polish.
The implementation plan should turn the selected semantics into small accepted and rejected examples, define the unresolved foundations, and stage features without pretending the entire language already fits into a minimal first release.