Roadmap

This page describes the planned development path for Loft and loft. Features marked planned are not yet available — the code examples show the intended syntax once the feature ships.

Current status — version 0.x

The language is under active development. All features documented on the language pages work correctly and are stable enough for real use, but the stability guarantee (no breaking changes) does not apply until version 1.0.

What works today:

• All primitive types: integer, long, float, boolean, text
• Structs and struct-enums with methods
• Collections: vector, sorted, index, hash
• Functions, default parameters, reference parameters (&), const parameters
• Function references (fn name) and higher-order functions (map, filter, reduce)
• File I/O: text, binary, directory listing
• Parallel execution: par(…) for-loop clause and parallel_for()
• Logging framework
• Library system (use mylib;)
• Null safety: every type is nullable; not null annotation on struct fields
• Format strings with expression interpolation: "{x * 2 + 1}"

Version 1.0 — Language stability

Version 1.0 is a stability contract: any program that works on 1.0 will compile and run identically on all future 1.x releases. The language surface — syntax, type system, documented standard library, command-line flags — is frozen at 1.0.

The primary gate items are correctness fixes (no panics on valid programs) and infrastructure (correct project identity, CHANGELOG, release binaries). See the internal planning documents for the full gate list.

The following features are target items for 1.0 — they are planned for the 1.0 release but will ship in 1.1 if they are not ready in time:

Match expressions planned

A match expression dispatches on an enum value with compiler-checked exhaustiveness. If every variant is not covered and no wildcard arm is present, the compiler reports an error.

// Plain enum dispatch
direction = North;
label = match direction {
    North => "north"
    East  => "east"
    South => "south"
    West  => "west"
};
assert(label == "north", "match direction");

// Struct-enum: each arm binds the variant's fields
area = match shape {
    Circle { radius }       => PI * radius * radius
    Rect   { width, height } => width * height
};

// Wildcard arm catches anything not listed above
description = match code {
    200 => "ok"
    404 => "not found"
    _   => "unknown"
};

Today the same logic requires an if/else chain or a dispatched method. Match makes it shorter and adds exhaustiveness checking.

Wildcard and selective imports planned

The current use mylib; import requires prefixing every name with mylib::. Two shorter forms are planned:

use mylib::*;              // bring all public names into scope
use mylib::Point, add;    // bring specific names into scope

The compiler will report a collision error if a wildcard-imported name shadows a local definition.

Code formatter planned

A canonical formatter enforces one consistent Loft style — 2-space indentation, opening braces on the same line, 80-column line wrapping. No configuration.

loft --format my_program.loft       # format in-place
loft --format-check my_program.loft  # exit 1 if formatting differs (CI)
loft --format src/                   # format every .loft file in a directory

The formatter is a token-stream pass that preserves all comments and produces a deterministic output. It does not require the program to type-check successfully.

Version 1.1 — Ergonomics

Lambda expressions planned

Today, passing a function to map or filter requires a named top-level function. Lambda expressions let you write the function body inline without giving it a name:

nums = [1, 2, 3, 4, 5];

// Today: requires a named function
fn double(x: integer) -> integer { x * 2 }
doubled = map(nums, fn double);

// With lambdas: inline, no top-level declaration needed
doubled = map(nums, fn(x: integer) -> integer { x * 2 });
evens   = filter(nums, fn(x: integer) -> boolean { x % 2 == 0 });
total   = reduce(nums, 0, fn(acc: integer, x: integer) -> integer { acc + x });

Lambdas do not capture surrounding variables in the first version — context must be passed explicitly. Closure capture is a longer-term item.

Interactive mode (REPL) planned

Running loft with no arguments will enter an interactive session where each expression is evaluated immediately and its result printed:

$ loft
> x = 42
> "{x * 2}"
84
> struct Point { x: float, y: float }
> p = Point { x: 1.0, y: 2.0 }
> p.x + p.y
3.0

Variable and type definitions persist across lines for the duration of the session. A parse error discards the failed line and continues the session.

Web IDE — independent track

A fully serverless browser-based IDE for Loft is being developed in parallel with the interpreter. It will run the full loft interpreter as a WebAssembly module — no installation, no account, no server.

Planned features:

• Syntax highlighting with the CodeMirror 6 editor
• Run button → console output and problems panel
• Go-to-definition and find-usages (Ctrl+click)
• Multiple projects stored locally in the browser (IndexedDB)
• Documentation and example browser without leaving the IDE
• One-click ZIP export with a structure ready for local loft development
• Works offline after first load (PWA service worker)

The web IDE does not depend on interpreter version 1.0 and will be released on its own timeline.

Following progress

Development is tracked in the GitHub repository. The internal planning documents describe each item in detail, including implementation notes and effort estimates.