Future Features
Planned features and future work for the Ashes language and ecosystem. Shipped features are documented in the normative docs under docs/md/ — syntax/semantics in Language Spec, library APIs in Standard Library, runtime/backend behavior in Architecture, and the history of the compiler's optimization/codegen work in the Compiler Changelog — not here.
The RC Perceus memory model has shipped. Its current contract is documented in Compiler Architecture; the compiler changelog preserves the phased implementation, paper comparison, validation evidence, and intentional region/thread boundaries.
| Feature | Status | Description |
|---|---|---|
| Traits / Typeclasses | Planned | Type-directed dispatch on the capability dictionary machinery, retiring the polymorphic-operator inlining hacks |
| Package Registry Website | Planned | Server-rendered browse/search UI over the existing registry API, surfacing per-package capability requirements |
| Self-Hosting | Exploratory | Rewrite the compiler in Ashes |
| WebAssembly Target | Exploratory | A wasm32 backend for browsers and sandboxed plugin hosts |
Ground Rules
- Spec first. Update the Language Reference before implementing any new syntax or semantic rule.
- Layer discipline. Respect the project dependency graph (Frontend → Semantics → Backend). Runtime behaviour never goes in Frontend.
- Test every invariant. Each feature must ship with tests that prove the new guarantees.
- No user-visible
Drop.Dropis a compiler concept. Users see automatic cleanup. - Purity preserved. All values are immutable. There is no mutation. All APIs — standard library and user-defined — are pure: they return new values and never modify their arguments. There are no in-place updates visible to user code.
- No tracing GC. Ordinary lifetime operations are compiler-inserted; resource cleanup remains statically verified.