Skip to content

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 Draft proposed / active std.archive — archive container creation and extraction
RFC 063 Draft 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 Draft proposed / active 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 Draft proposed / active 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 Draft proposed / active std.re — Pythonic regular expressions
RFC 101 Done closed / implemented std.collections.OrdinalMap — deterministic compact key-to-ordinal lookup
RFC 102 Draft proposed / active Incan Semantic Layer Inspection Surface
RFC 103 Draft 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 Draft proposed / active Compiler-backed agent context graph
RFC 107 Draft proposed / active Type-directed library APIs and compile-time type tokens

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 near-term roadmap is therefore split into six release lanes:

  • Tooling and first-contact inspection.
  • Backend replacement foundation.
  • Backend cutover.
  • Broader feature reopening after the compiler architecture is no longer split between old and new semantic paths.
  • Freestanding target foundations.
  • Kernel capability proof before 1.0 stabilization.

Release Milestones

0.4 Release: tooling and inspection

The 0.4 milestone is the tooling and inspection release. It focuses on:

  • canonical SDK install path;
  • zero-clone starter flow;
  • first-contact docs and positioning;
  • stable machine-readable diagnostics;
  • diagnostic explain catalog;
  • codegraph export for agent/maintainer code intelligence;
  • generated Rust and emitted artifact inspection;
  • build reports.

New language/runtime feature work is out of scope unless it directly supports that tooling path.

Core tracking issues:

  • #223: 0.4 tooling, inspection, and first-contact umbrella.
  • #428: canonical SDK installer and release manifest.
  • #553: zero-clone starter project flow.
  • #551: first-contact quickstart and positioning docs.
  • #554: release direction notes and scope guard.
  • #573: codegraph export.
  • #589: stable JSON diagnostics.
  • #590: diagnostic explain catalog.
  • #591: build artifact report.
  • #567: generated Rust inspection tooling and quality gates.
  • #592: RFC template inspectability prompts, if tiny and opportunistic.

0.5 Release: backend foundation and Hees.ai proof lane

The 0.5 milestone begins deprecating the Rust-source backend as the semantic path. It introduces the compiler foundations needed for a backend-neutral middle end:

  • stable compiler IDs;
  • backend-neutral semantic facts;
  • IncanType and semantic type modeling;
  • ABI v0 design hooks;
  • HIR v0;
  • behavior inventory;
  • backend migration scaffolding.

Stdlib RFC/work is allowed in this lane. Hees.ai is also allowed, but only as a constrained commercial and dogfood proof path that validates compiler, stdlib, runtime, and tooling direction. Hees.ai work should consume general Incan surfaces, not quietly become broad product scope inside the language milestone.

Core tracking issues:

  • #634: v1.0 middle-end foundation umbrella.
  • #646: current compiler behavior inventory.
  • #647: deprecate Rust-source backend as semantic path.
  • #648: stable compiler IDs and semantic facts database.
  • #649: IncanType semantic type model and ABI v0 hooks.
  • #650: HIR v0 and snapshot tests.
  • #282: backend orchestration migration scaffolding.
  • #224: CompilationSession semantic database transition.
  • #549: Hees.ai governed workbench demo.
  • #651: Hees.ai dependency inventory and guardrails.

Allowed stdlib work includes std.http, std.ci, CLI framework, std.archive, std.process, std.web lifecycle, std.environ, package-level timezones, fallible reader chunk streams, and selected stdlib compilation/source-authored behavior work.

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.
  • InQL and Pallay SDK 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, hosted std, 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

Interested in contributing?

See the Contributing page for more information about contributing to Incan.