Incan Roadmap¶
This page tracks implementation status, release scope, and sequencing.
Incan development is driven by RFCs (Request for Comments).
- An RFC captures a design proposal for a feature, including syntax, semantics, and implementation details.
- RFCs are not necessarily implemented in the order they are written.
- Milestones track release posture and sequencing. They define scope, not urgency.
See the RFCs page for more information about RFCs.
RFC status table¶
This table is autogenerated from the RFC files (it reads each RFC’s **Status:** ... line).
Tip: press Esc to clear.
| RFC | Status | Track | Title |
|---|---|---|---|
| RFC 000 | Done | closed / implemented | Incan Core Language RFC (Phase 1) |
| RFC 001 | Superseded | closed / superseded | Test Fixtures |
| RFC 002 | Superseded | closed / superseded | Parametrized Tests |
| RFC 003 | Superseded | closed / superseded | Frontend and WebAssembly Support |
| RFC 004 | Done | closed / implemented | async fixtures |
| RFC 005 | Done | closed / implemented | Rust Interop |
| RFC 006 | Done | closed / implemented | Python-style generators |
| RFC 007 | Superseded | closed / superseded | Inline Tests |
| RFC 008 | Done | closed / implemented | Const Bindings |
| RFC 009 | Done | closed / implemented | Numeric type system and builtin type registry |
| RFC 010 | Done | closed / implemented | Python-style tempfile standard library |
| RFC 011 | Done | closed / implemented | Precise Error Spans in F-Strings |
| RFC 012 | Superseded | closed / superseded | JsonValue, enum methods, and enum trait adoption |
| RFC 013 | Done | closed / implemented | Rust Crate Dependencies |
| RFC 014 | Rejected | proposed / active | user-facing runtime error behavior for generated code |
| RFC 015 | Done | closed / implemented | hatch-like tooling (project lifecycle CLI) |
| RFC 016 | Done | closed / implemented | loop and break <value> (Loop Expressions) |
| RFC 017 | Done | closed / implemented | Validated newtypes with implicit coercion (pydantic-like feel) |
| RFC 018 | Done | closed / implemented | language primitives for testing |
| RFC 019 | Done | closed / implemented | test runner, CLI, and ecosystem |
| RFC 020 | Done | closed / implemented | offline / locked / reproducible builds (Cargo policy + generated project contract) |
| RFC 021 | Done | closed / implemented | Model field metadata and schema-safe aliases |
| RFC 022 | Done | closed / implemented | Namespaced stdlib modules and compiler→stdlib handoff |
| RFC 023 | Done | closed / implemented | Compilable Stdlib & Rust Module Binding |
| RFC 024 | Done | closed / implemented | extensible derive protocol |
| RFC 025 | Done | closed / implemented | multi-instantiation trait dispatch |
| RFC 026 | Superseded | closed / superseded | User-Defined Trait Bridges |
| RFC 027 | Done | closed / implemented | incan-vocab — Library Vocabulary Registration Crate |
| RFC 028 | Done | closed / implemented | trait-based operator overloading |
| RFC 029 | Done | closed / implemented | union types and type narrowing |
| RFC 030 | Done | closed / implemented | std.collections — extended collection types |
| RFC 031 | Done | closed / implemented | Incan Library System — Phase 1 (Local Path Dependencies) |
| RFC 032 | Blocked (by RFC 033) | proposed / active | value enums — StrEnum and IntEnum |
| RFC 033 | Draft | proposed / active | ctx — typed configuration context |
| RFC 034 | Draft | proposed / active | incan.pub — The Incan Package Registry |
| RFC 035 | Done | closed / implemented | First-Class Named Function References |
| RFC 036 | Done | closed / implemented | user-defined decorators |
| RFC 037 | Planned | proposed / active | native web stdlib redesign |
| RFC 038 | Done | closed / implemented | Variadic Args and Unpacking (*args / **kwargs) |
| RFC 039 | Done | closed / implemented | race for awaitable concurrency |
| RFC 040 | Done | closed / implemented | Scoped DSL Surface Forms |
| RFC 041 | Done | closed / implemented | First-Class Rust Interop Authoring |
| RFC 042 | Done | closed / implemented | Traits Are Always Abstract |
| RFC 043 | Done | closed / implemented | Rust Trait Implementation from Incan |
| RFC 044 | Done | closed / implemented | Open-Ended Trait Methods |
| RFC 045 | Done | closed / implemented | Scoped DSL symbol surfaces |
| RFC 046 | Done | closed / implemented | Computed properties (property name -> Type) |
| RFC 047 | Done | closed / implemented | Lightweight directed graph types (stdlib) |
| RFC 048 | Done | closed / implemented | Checked contract metadata, Incan emit, and interrogation tooling |
| RFC 049 | Done | closed / implemented | if let and while let pattern control flow |
| RFC 050 | Done | closed / implemented | Enum methods and enum trait adoption |
| RFC 051 | Done | closed / implemented | JsonValue for std.json |
| RFC 052 | Done | closed / implemented | Module Static Storage |
| RFC 053 | Done | closed / implemented | Formatter vertical spacing (three blank-line buckets) |
| RFC 054 | Done | closed / implemented | Explicit call-site generic arguments for function and method calls |
| RFC 055 | Done | closed / implemented | std.fs — pathlib-shaped filesystem APIs with chunked file I/O |
| RFC 056 | Done | closed / implemented | std.io — in-memory byte streams and binary parsing helpers |
| RFC 057 | Done | closed / implemented | @rust.allow(...) — targeted Rust lint suppression for generated code |
| RFC 058 | Done | closed / implemented | std.datetime — temporal values, intervals, and runtime timing |
| RFC 059 | Done | closed / implemented | std.regex — regular expressions, matches, captures, and replacement |
| RFC 060 | Done | closed / implemented | std.uuid — UUID parsing, generation, and formatting |
| RFC 061 | Done | closed / implemented | std.compression — codec-based compression and decompression |
| RFC 062 | Planned | proposed / active | std.archive — archive container creation and extraction |
| RFC 063 | Planned | proposed / active | std.process — process spawning and command execution |
| RFC 064 | Done | closed / implemented | std.encoding — binary-text encoding and decoding utilities |
| RFC 065 | Done | closed / implemented | std.hash — stable hashing primitives for data and integrity workflows |
| RFC 066 | Draft | proposed / active | std.http — Incan-first HTTP client and request/response surface |
| RFC 067 | Draft | proposed / active | std.ci — deterministic CI and automation scripting primitives |
| RFC 068 | Done | closed / implemented | protocol hooks for core language syntax |
| RFC 069 | Done | closed / implemented | list.repeat Helper for Fixed-Length Initialization |
| RFC 070 | Done | closed / implemented | Result Combinators for Result[T, E] |
| RFC 071 | Done | closed / implemented | Pattern alternation in match and if let |
| RFC 072 | Done | closed / implemented | std.logging — logger acquisition, configuration, and structured events |
| RFC 073 | Draft | proposed / active | environment matrices and toolchain constraints |
| RFC 074 | Draft | proposed / active | template rendering and boilerplate provenance |
| RFC 075 | Draft | proposed / active | starter profiles and capability packs |
| RFC 076 | Draft | proposed / active | project mutation policy and recovery |
| RFC 077 | Done | closed / implemented | workspace and multi-package projects |
| RFC 078 | Draft | proposed / active | tool execution and typed workflow actions |
| RFC 079 | Draft | proposed / active | incan.pub artifact graph |
| RFC 080 | Draft | proposed / active | AI assets, models, prompts, evals, and agent metadata |
| RFC 081 | Draft | proposed / active | Language-shaped DSL embeddings |
| RFC 082 | Draft | proposed / active | Checked API documentation generation |
| RFC 083 | Done | closed / implemented | Symbol and method aliases |
| RFC 084 | Done | closed / implemented | RHS partial callable presets |
| RFC 085 | Planned | proposed / active | Field metadata and type-shaped constraints |
| RFC 086 | Planned | proposed / active | Schema descriptors and adapters |
| RFC 087 | Planned | proposed / active | Reusable field contracts and structural model composition |
| RFC 088 | Done | closed / implemented | Iterator adapter surface |
| RFC 089 | Done | closed / implemented | std.environ runtime environment access |
| RFC 090 | Draft | proposed / active | typed CLI framework |
| RFC 091 | Draft | proposed / active | Constrained integer newtype storage carriers |
| RFC 092 | Draft | proposed / active | Interactive Runtime Stdlib Contracts |
| RFC 093 | Draft | proposed / active | std.telemetry — OpenTelemetry-aligned observability |
| RFC 094 | Draft | proposed / active | Context managers |
| RFC 095 | Draft | proposed / active | span vocabulary blocks |
| RFC 096 | Draft | proposed / active | Declaration metadata blocks |
| RFC 097 | Draft | proposed / active | Rust-hosted Incan caller |
| RFC 098 | Draft | proposed / active | Native associated types for traits |
| RFC 099 | Draft | proposed / active | Generic trait-targeted methods |
| RFC 100 | Planned | proposed / active | std.re — Pythonic regular expressions |
| RFC 101 | Done | closed / implemented | std.collections.OrdinalMap — deterministic compact key-to-ordinal lookup |
| RFC 102 | Planned | proposed / active | Incan Semantic Layer Inspection Surface |
| RFC 103 | Planned | proposed / active | std.secrets — Secret strings, secret bytes, and redaction-safe values |
| RFC 104 | Draft | proposed / active | Ambient Runtime Capabilities and Receipts |
| RFC 105 | Draft | proposed / active | incan architect rule engine for design, safety, idiom, maintainability, and risk findings |
| RFC 106 | Planned | proposed / active | Compiler-backed agent context graph |
| RFC 107 | Draft | proposed / active | Type-directed library APIs and compile-time type tokens |
| RFC 108 | Draft | proposed / active | Import-scoped extension properties |
| RFC 109 | Draft | proposed / active | Receiver chain combinators (tap and then) |
| RFC 110 | Draft | proposed / active | Comparable trait and derive |
| RFC 111 | Draft | proposed / active | Proof-aware agentic contract feedback |
| RFC 112 | Done | closed / implemented | Crash-safe local publication and file coordination |
| RFC 113 | Done | closed / implemented | std.registry and declaration descriptors |
| RFC 114 | Done | closed / implemented | Compiled providers, SDK components, and package features |
| RFC 115 | Done | closed / implemented | Fallible iteration and combinators |
| RFC 116 | Done | closed / implemented | Typed C ABI interop |
| RFC 117 | Draft | proposed / active | Loaf.toml and Oven's language-neutral project model |
| RFC 118 | Draft | proposed / active | Incan and Oven command-line surfaces |
| RFC 119 | Draft | proposed / active | Oven-native Rust build facets and Cargo interoperation |
Strategic Direction¶
Incan's current direction is:
Python-readable at the base, domain-native at the edges, compiler-inspectable all the way down.
That means Incan should not compete as a small systems language or as a generic Python clone. The compiler, standard library, and tooling should make domain packages, capability metadata, policy, generated artifacts, diagnostics, and backend facts inspectable by humans and agents.
The completed releases below show how Incan reached its current compiler and project foundation. The forward roadmap is split into five release lanes:
- 0.6: backend cutover.
- 0.7: broader feature reopening after the compiler architecture is no longer split between old and new semantic paths.
- 0.8: freestanding target foundations.
- 0.9: kernel capability proof.
- 1.0: stabilization and public contracts.
Release Milestones¶
The completed release lines are kept here as a compact history. Expand a release for its outcome and boundary; follow the release-note link for the complete change inventory. The active roadmap begins with 0.6 below.
Completed release history
0.1 — The first published Incan release
Outcome: establish a usable language, compiler, CLI, and documentation baseline.
Incan 0.1 shipped the core Python-shaped language surface, typed models and control flow, Result/Option, modules, early Rust interop, incan build / run / fmt / test, generated language reference material, and the first multi-file typed web applications. It proved that Incan could be used as a language rather than only explored as a compiler experiment.
Boundary: the package and standard-library model was still young, Rust interop used a narrower known-good surface, and several compiler/library capabilities were explicitly incomplete.
0.2 — Explicit modules, libraries, and a serious Rust boundary
Outcome: turn the first language surface into a more coherent platform.
Incan 0.2 moved standard-library and decorator surfaces under explicit std.* modules, separated Incan dependencies from Rust crate dependencies, introduced experimental Incan libraries, strengthened rust:: interop and rusttype, added module-owned static state, and made generic call sites and package boundaries more explicit. The release replaced ambient compiler magic with named, import-driven capabilities.
Boundary: libraries remained experimental and the release did not yet provide a complete package ecosystem or remove generated-Rust ownership friction.
0.3 — Real application code, broader stdlib, and stronger tooling
Outcome: make larger programs feel deliberate instead of improvised.
Incan 0.3 expanded expression-oriented control flow, typed numerics, enums, protocols, decorators, partial callables, generators, lazy iteration, and Result combinators. It also broadened the source-authored standard library across collections, graphs, JSON, regex, datetime, logging, encoding, hashing, compression, filesystem, I/O, and UUIDs while strengthening tests, formatting, locks, Rust interop, and generated-output discipline.
Boundary: real programs became credible, but installation, first-contact diagnostics, machine-readable inspection, and cross-boundary parity still needed a dedicated release.
0.4 — Tooling, inspection, and first contact
Outcome: make the stack tryable without cloning the compiler repository or reverse-engineering its internals.
Incan 0.4 delivered the canonical installer and zero-clone starter flow, stable machine-readable diagnostics, incan explain, build reports, generated-Rust inspection, compiler-backed codegraph export, visible build/test preparation, and compact boundary-parity fixtures. A new evaluator could install Incan, create and run a project, understand failures, inspect generated artifacts, and export compiler facts for tools and agents.
Boundary: 0.4 deliberately did not reopen broad language/runtime scope, replace the backend, establish a public Rust ABI, or turn downstream Encero proof lanes into product releases.
0.5 — Compiler-owned foundations and checked project boundaries
Outcome: give ordinary applications, libraries, workspaces, packages, and native integrations one checked compiler view.
Incan 0.5 moved critical commands onto shared CompilationSession analysis and landed the backend-neutral foundations for stable compiler identities, semantic facts, IncanType, initial HIR, ABI hooks, and backend migration. Those foundations deprecate generated Rust as semantic authority without pretending the backend cutover is complete.
The same release made package and project boundaries materially stronger:
- implemented rooted and virtual multi-package workspaces with deterministic member selection, shared dependency and environment inheritance, portable locking, inspection, and lifecycle fan-out (RFC 077);
- added compiled providers, SDK components, package-owned features, typed registries, declaration descriptors, crash-safe local publication, and more stable cross-machine identities;
- delivered operational standard-library surfaces and fallible iteration needed by representative applications and downstream proof lanes;
- delivered an experimental, deliberately bounded typed C ABI with checked signatures, ownership, layouts, artifacts, and target evidence (RFC 116); and
- introduced Oven Alpha as a narrow evidence-backed build path inside the documented 0.5 envelope, not as the release's primary story or a claim of general Cargo-workspace replacement.
Boundary: generated Rust remains inspectable backend output; the replacement-backend cutover belongs to 0.6. Oven remains Alpha. The Hees.ai work validates the compiler, standard library, runtime, and tooling as a downstream proof lane; it is not a Hees.ai product release.
The original foundation trackers—#634, #646, #647, #648, #649, #650, #282, and #224—are complete. The release notes retain the full user-facing and issue-level inventory.
Forward roadmap
0.6 Release: backend cutover¶
The 0.6 milestone removes the Rust-source backend from the normal compiler path. The replacement backend should preserve supported behavior, report compatibility/migration details, and retire generated Rust as the semantic handoff.
Only runtime/DSL RFC scope that stress-tests or supports the new backend belongs here.
Core tracking issues:
- #652: replacement backend parity cutover.
- #653: Body IR v0 and backend-owned lowering.
- #654: remove Rust-source backend and generated-Rust semantic handoff.
- #655: backend compatibility report and migration notes.
- #225: semantic facts adoption on backend cutover paths.
- #656: Rust-facing ABI and Cargo-native Incan package direction.
- #752: RFC 107 type-directed library APIs and compile-time type tokens.
- RFC 092: interactive runtime stdlib contracts.
- RFC 093:
std.telemetry. - RFC 094: context managers.
- RFC 107: type-directed library APIs and compile-time type tokens.
- RFC 095: span vocabulary blocks.
0.7 Release: feature reopening¶
The 0.7 milestone is the broader feature reopening lane after the backend replacement is complete. This is where deferred language, package, registry, lifecycle, interop, docs-generation, editor, and product-surface work can resume.
Examples of deferred lanes:
- incan.pub and package registry/product identity.
- IncQL and Pallay toolchain dogfood.
- source-local feature metadata.
- Python interop research.
- checked API docs generation.
- Windows/package-manager/self-upgrade convenience work.
- trait/newtype language features not required by backend cutover.
- broader editor and package lifecycle work.
0.7 should not absorb freestanding/kernel primitives by default. That work needs its own release lanes so feature reopening does not become the place where unsafe, layout, target, runtime, and kernel proof work all land at once.
0.8 Release: freestanding foundations¶
The 0.8 milestone defines the compiler, runtime, ABI, and package foundations needed for freestanding targets. It should make low-level targets possible without promising a production kernel or stabilizing every low-level surface.
The release should answer how Incan code can compile without assuming hosted std, a process environment, filesystem access, threads, default allocator availability, or ordinary hosted panic behavior.
Expected scope:
- freestanding target profiles and capability manifests;
- runtime layering across
core,alloc, hostedstd, and future kernel-facing APIs; - no-std/freestanding build mode;
- panic strategy and allocator hooks;
- ABI/layout/repr/alignment/calling-convention controls;
- an explicit unsafe model for raw pointers, volatile access, MMIO, and low-level intrinsics;
- package metadata for freestanding compatibility.
Core tracking issues:
- #681: RFC proposal for freestanding targets and runtime layering.
- #682: RFC proposal for unsafe blocks and low-level operations.
- #683: RFC proposal for representation, layout, and calling convention controls.
- #684: stdlib/runtime layer inventory for freestanding foundations.
- #685: freestanding target profiles and runtime requirement reports.
- #686: no-std freestanding build mode and restricted artifact smoke test.
- #687: unsafe low-level operation surface v0.
- #688: layout, repr, and calling-convention metadata v0.
- #689: panic strategy and allocator hooks for freestanding targets.
0.8 is successful when Incan can compile a restricted freestanding artifact and report which runtime, allocator, panic, target, and ABI capabilities it requires.
0.9 Release: kernel capability proof¶
The 0.9 milestone is the vertical proof that the freestanding foundations work under real low-level pressure. It should boot a tiny Incan-authored kernel under an emulator, not ship a production operating system.
Expected scope:
- minimal architecture support layer;
- linker and boot configuration;
- QEMU runner and smoke harness;
- serial output;
- panic halt/report path;
- allocator hookup;
- MMIO/volatile/raw pointer use;
- one interrupt, timer, or simple task proof.
Core tracking issues:
- #690: QEMU tiny kernel capability proof.
0.9 is successful when Incan can build and boot a tiny freestanding kernel under QEMU with Incan-authored init logic and a concrete low-level capability proof.
1.0 Release: stabilization and public contracts¶
The 1.0 milestone consolidates the post-cutover compiler architecture, ABI/package direction, tooling contracts, stdlib maturity, ecosystem workflows, freestanding lessons, and documentation into a coherent public surface.
1.0 should describe what Incan is, what it guarantees, how packages and generated artifacts are consumed, where Rust-facing interop boundaries are stable, and which freestanding/kernel-facing surfaces are stable, experimental, or intentionally deferred.
Status by Area¶
- Core language: see RFC 000 / RFC 008.
- Testing surface: see RFC 018 / RFC 019 / RFC 004.
- Tooling and first-contact: install, starter, diagnostics, explain, codegraph, artifact inspection, and build reports are the immediate release surface.
- Rust interop: see RFC 005 / RFC 013 and the Rust Interop guide. Rust-hosted consumption should be reframed through ABI and Cargo-native package direction instead of generated Rust as the public semantic path.
- Web and interactive runtime: see the Web Framework guide, RFC 092, and related runtime/DSL RFCs.
- Standard library: stdlib work is allowed in the backend-foundation lane where it helps real programs and dogfood paths validate compiler/runtime direction.
Deferred / Later¶
The following items remain intentionally deferred until they have a focused RFC or implementation lane:
- SSR/SSG for frontend: Server-Side Rendering / Static Site Generation for the WASM/UI stack (render pages ahead of time or on the server, then hydrate).
- Desktop/mobile via wgpu: using the wgpu graphics stack to run Incan apps as native desktop/mobile apps instead of browser-only.
- CRDT/collab features: real-time collaboration primitives (Conflict-free Replicated Data Types) for collaborative editing, shared state, and similar workflows.
Guides¶
- Web framework guide: Web framework guide
- Rust interop guide: Rust interop
- Testing guide: Testing
Interested in contributing?¶
See the Contributing page for more information about contributing to Incan.