This page is the maturity boundary for the Language Guide. It separates current source contracts from syntax that is only represented, subsystems that are still moving, and historical application-framework proposals.
Implementation ladder
A feature advances through the compiler in a strict order:
lex and parse
↓
resolve and check
↓
lower to HIR
↓
specialize and lower to MIR
↓
emit and validate WebAssembly
↓
execute through the runtimeThe strongest completed rung determines what the book may claim:
| Maturity | Meaning | Appropriate documentation |
|---|---|---|
| Represented | Tokens or AST nodes exist | Grammar notes, with an explicit “no semantics yet” warning |
| Checked | Resolution, typing, effects, and HIR define the construct | Language semantics, while backend availability remains qualified |
| Lowered | Monomorphization and MIR preserve the behavior | Compiler design and IR contracts |
| Emitted | Valid WebAssembly is produced without a fallback | Backend and ABI documentation |
| Executed | Source-to-runtime tests exercise the behavior | User-facing examples and operational guarantees |
Diagnostics at a missing rung are part of the contract. A compiler that rejects an unsupported backend case with a source diagnostic is more complete than one that substitutes a value, drops an operation, or panics.
Current boundary
The guide’s broad feature families currently sit at different strengths:
| Area | Current book contract |
|---|---|
| Bindings, expressions, functions, control flow, nominal types, and typed errors | Core syntax and semantic behavior are documented from parser and checker evidence; individual backend edges are called out where relevant |
| Modules and projects | Multi-file loading, imports, visibility, and project-wide checking are current; incremental granularity is a compiler concern, not a language guarantee |
| Tasks, suspension, cancellation, streams, and concurrency combinators | Implemented core with runtime-sensitive behavior; pages distinguish checked effects from scheduling guarantees |
| Models, schemas, queries, frames, and writes | Integrated data subsystem with provisional edges; each page identifies whether its claim comes from parsing, semantic query planning, lowering, or end-to-end execution |
| Decorators | Generic syntax is represented; only named compiler-recognized decorators have semantics |
| Raw pointers and unsafe operations | Narrow, explicitly unsafe surface guarded by MIR validation; not a general escape from ownership or suspension rules |
| Standard-library APIs | Only declarations installed by the current prelude are treated as built in; old docs/builtin/ proposals are not silently promoted |
This table is intentionally conservative. A page can provide a stronger, source-backed statement for one operation without promoting its entire subsystem.
Historical declarations
Several legacy documents are product and application-framework proposals, not the syntax accepted by the current declaration parser:
| Legacy concept | Current status |
|---|---|
actor, actor messages, supervision |
Historical proposal; no ActorDecl |
service declarations and implicit service wiring |
Historical proposal; use structs, traits, functions, and modules |
topic and messages declarations |
Historical proposal; use current Stream[T]/host APIs where appropriate |
job and workflow declarations |
Historical proposal; scheduling/orchestration requires a host/library layer |
Implicit context parameters |
Historical proposal; no current context declaration or implicit threading rule |
| UI, auth, AI, MCP, route, event, actor, and job decorator catalogs | Domain designs; generic decorator syntax parses, but these behaviors are not supplied by the core compiler |
| Old model inheritance/behaviors | Superseded; current model is the integrated SQL persisted-row declaration |
| Logger facade and automatic error logging | No current logger prelude; println and host logging integrations are separate |
Library proposals
Several files under docs/builtin/ describe useful domain APIs that are not in
the installed core prelude:
| Legacy API | Current status |
|---|---|
Any runtime type erasure |
No current Any prelude type or dynamic downcast contract |
Email, Phone, and Url |
Domain validation proposals; use application structs and constructors |
Money |
Domain arithmetic proposal; no current currency-aware scalar |
Queue and Stack |
No nominal prelude types; use List[T] with an application wrapper when those invariants matter |
Absence from the prelude does not prevent a library from defining these types. It means their validation, arithmetic, storage, and serialization behavior are not universal language contracts.
The parser may still reserve a word or preserve a decorator even when no declaration, semantic check, lowering, or runtime exists for the proposed feature. Parseability alone is not implementation.
Review checklist
Before moving a page from provisional to verified, its reviewer should be able to answer all of these:
- Which lexer/parser paths accept the syntax, and what diagnostics recover from malformed input?
- Which resolver and checker paths define names, types, effects, visibility, and error behavior?
- Does the HIR preserve every value the later stages need?
- Do generic uses specialize correctly, and do MIR validators accept the lowered program?
- Does code generation produce validator-clean WebAssembly without a silent fallback?
- Is there an executable test for behavior that depends on the runtime?
- Do all examples use current naming, builtin spellings, and interpolation syntax?
Not every page needs evidence from all seven points. A syntax reference can be verified at the syntax boundary, but it must not claim execution. A runtime guarantee does need the entire path.
Page labels
- Verified pages are checked against current parser/sema/prelude or runtime tests.
- Provisional pages describe an implemented core whose edge features or public contract are still moving.
- Historical pages preserve context but do not define current syntax or behavior.
- Planned designs live outside the Language Guide until the complete source-to-runtime path exists.
This boundary keeps valuable design work available without making unsupported application syntax look production-ready. For how those rungs map onto crates and intermediate representations, continue to Pipeline.