Proposals
Proposals record design rationale and rejected alternatives. The reference defines current behavior; the backlog tracks future work. If a proposal disagrees with the reference, follow the reference.
Status
Each main proposal opens with a status note linking to the governing reference, identifying differences in what shipped, and naming remaining backlog items. Companion pages identify their parent and whether their examples are hypothetical.
| Status | Meaning |
|---|---|
| Implemented | The design shipped. The page keeps the rationale. |
| Partly implemented | Some of it shipped. The block says which parts. |
| Not implemented | Nothing shipped. The page is the design record for future work. |
| Investigation complete | An assessment reached a decision; it does not imply feature implementation. |
Proposal text retains its original wording: it may describe shipped features as future work or show syntax that never shipped. Proposal code is not compiled by the test suite.
When a change implements or alters a design, update its status note. Move a
proposal to completed/ when its agreed scope ships or its
investigation concludes without an implementation commitment;
retain its rationale and update links and book navigation. Alternatives and
future extensions need not ship for the agreed scope to be complete. Keep
partly implemented and unimplemented proposals here; retain superseded or
abandoned designs separately in archived/ when needed.
The status scan used reference, implementation, and regression coverage at
local main commit 74fa81d8 on 2026-10-20; it did not rerun every feature
test. Later reviews reconciled HTTP acceptance, error composition, and anonymous
sums at 4e40c4fc on 2026-10-23, and entry points, modules, executable
lessons, and the next language phase at 161e1c63 on 2026-10-24.
Find a design by topic
Companion examples and evidence do not imply additional implementation commitments.
Completed
See Completed proposals for shipped designs and their reference pages. Further extensions remain tracked in the backlog.
Partly implemented
| Proposal | Shipped | Remaining |
|---|---|---|
| Value generic parameters | Value parameters and Bounded | B83 arrays/assertions; B96 std adoption |
| Recursive owned data | Recursive storage through Box[T] | B11, B33 |
| Typed ranges, generic calls, and expression-local inference | Typed ranges, contextual literals, explicit type arguments | B12, B16, B32 |
| C interop and dynamic libraries | Imports, linking, exports, and resident loading | B18, B27, B28 |
| Generated library contracts and C headers | Exports, contracts | B27, B28 |
| Fallible memory, parallel execution, and SIMD | Fallible allocation, concurrency, initial SIMD | B13 allocator control; B23 SIMD extensions; B24 automatic parallelization; B83 fixed arrays |
| Standard library scope | Embedded library, including data formats, TLS, HTTP, SQLite, signals and testing | Remaining B38–B70 scope |
| Keyword arguments, defaults, and static unpacking | Named calls and fresh defaults under the narrower design | B36: splats and signature markers remain separate candidates |
| Units of measure | Dimensions and Quantity[T, D], erased to their storage type (issue #701) | B97: std.units, sharing bodies that differ only in dimension |
Not implemented
| Proposal | Backlog |
|---|---|
| Runtime-independent networking protocols — agreed codec/session/driver direction; complete shared WebSocket session and both drivers remain proposed | B94, B85 |
| Actor budgets and retained stacks — test-only heap/trap probe; compiler checkpoints and stage ownership integration remain unimplemented | B85 |
| Blocking work for actors — bounded native workers, independent job ownership and event-based completion | B85 |
| Async/await exploration — owned movable frames, fallible admission and synchronous cancellation; isolated spike only | Unscheduled exploration; async implementation remains out of scope pending an adoption decision |
| Cosmopolitan and Actually Portable Executables — bounded compatibility experiment before any runtime/platform commitment | B18, B17 |
| Package language editions — exploratory compatibility mechanism; no editions implemented | B17 |
| Using Rust crates in Plenty — three prototypes favor generated C adapters over a Cargo/rustc graph; production integration remains | B17, related B20 |
| Compiling Plenty to Rust source — checked-IR scalar emitter, native companion round-trip and Rust build-cost measurements; ownership probes remain hand-lowered, no production backend | B20, related B17 |
| Linear obligations, including aggregate and error rules — opt-in non-abandonment | B72 (issue #149) |
| Synchronous resolution scopes — consuming scope policy; depends on linear obligations | B72 (issue #149) |
| Linearity, typestate, and execution responsibility — shared boundaries and deferred worker/async contracts | B72 (issue #149) |
GCC backend (plenty_codegen_gcc) | B20 |
Portable std.simd and automatic pipeline SIMD — small portable API, bounded safe transformations, and backend spike evidence | B23; related B12, B19, B24, B75 |
| Columnar lists — explicit field-column storage, a bounded object facade, and native layout/ownership spikes | B76; related B11, B12, B23, B75 |
User-defined ordering — one three-way __cmp__ hook | B37 |
| Timsort for stable, adaptive sorting — fallible workspace, stability, and compatibility choices | B37 (issue #331) |
User-defined dictionary keys and set members — derived structural hashing and a KeyType bound | Structural class/enum/anonymous-sum keys, including custom cleanup, plus KeyType; copying operations require duplicable keys |
Derived serialization for classes and enums — @serial derives hooks against a JSON-shaped std.serial data model shared by JSON and TOML | None yet; candidate under B51/B38 (issue #471) |
Returned enums that carry references — Option[&T] and Result[&T, E] returned under the first-reference-parameter rule, held in locals, never stored | None yet; extends B11 (issue #516) |
| Go-style scoped tasks, with runtime choices and native spike evidence — exploratory fixed-stack alternative; no lightweight scheduler adopted | B22 investigation; implementation uncommitted |
| Arbitrary-precision integers — Plenty limbs with an inline small value; malachite rejected on allocation failure and LGPL | B38 (issue #481) |
| Thread-local reference counts — single-threaded phase first, then Lean/Koka-style thread-shared marks at certified boundaries; measured atomic count traffic | None yet; related issues #743–#746 |
| Faster linking — measured link costs; caching the executable, running the linker directly and reusing the extracted runtime archive; object-format changes do not pay | B19; related B17 |
Checked arithmetic by default — function-level typed errors, explicit unchecked: with a validated no-failure precondition and retained local checked: recovery; core/repository adoption and bounded validation complete; local review and merge pending | B14 |
Exact decimal arithmetic — allocation-free 38-digit Decimal in Plenty, scale kept with numeric equality as in Python, exact operators under the integer trap and checked: rules, NonZero[Decimal] divisors, explicit rounding | None yet; related B76, B37, B74 |
Numerics core — std.numeric in Plenty over std.linalg; a scoped SciPy subset in three milestones; basin and numeris not adopted | B38 (replaces issues #492, #493) |
| Six rules for a consistent core — one copy rule, one formatting path, owner-to-view conversion, adapters on iterators only, error types that name only what can fail, every callable form as a callback | None yet; proposes B88–B93; related B12, B49, B84 (issues #614–#636) |
Completed investigations
| Assessment | Decision / related backlog |
|---|---|
| Native macOS, Windows, and AArch64 support | Native ports need target-aware builds, ABI validation and OS/stdlib contracts before release packaging. B18, with B17/B12 dependencies. |
| Protocol method bodies | Core default/final dispatch and member-specific grants agreed; definition-time contract checking required. No automatic method injection. Not implemented or scheduled (B29). |
| Owned structures and checked node identities | Tested patterns and arena prototype; production identity/access contract remains B73, broader borrowing B11. |
| Typestate and owned transitions | Existing owned transitions and their limits; linear non-abandonment is a separate proposed extension (B72). |