Leaf Roadmap

This document outlines features planned for future versions of the language that are currently out of scope for the v1 specification.

Concurrency and Asynchronous I/O

Status: Out of scope for v1

Planned approach:

Leaf v1 is a single-threaded language with no concurrency primitives. Future versions will introduce asynchronous programming based on:

• Cooperative multitasking via coroutines — generators will serve as the foundation for async execution
• Single-threaded event loop — no threading or parallel execution at the language level
• Runtime support for "true" async operations — delegating blocking I/O (file reads, network requests, etc.) to runtime services while keeping the language semantics single-threaded

This model prioritizes simplicity and predictability. The mutability system (mut) is designed for single-threaded safety, not concurrency control.

Example (future syntax, not yet specified):

async fn fetch_data(url: str) -> Result[str, HttpError]
    response = await http.get(url)?
    return Ok(response.body)
end

async fn main()
    data = await fetch_data("https://example.com")?
    println("Received: {data}")
end

This is illustrative only — the actual syntax and semantics of async/await are not yet designed.

Other Future Features

Additional language features under consideration for post-v1 releases:

• Standard library expansion — comprehensive APIs for I/O, networking, collections, time, and system interaction
• Regular expression support — pattern matching on strings via a Regex type, likely as a standard library module (use regex) rather than built-in syntax; design questions include literal syntax (e.g., r"[a-z]+" raw strings vs. a constructor), match/capture API, and integration with str methods
• Error type hierarchy — standardized error types for common failure modes (I/O errors, parsing errors, etc.)
• Package management — tooling and conventions for third-party dependencies
• Compiler optimizations — tail-call optimization, dead code elimination, inlining
• Debugging support — source maps, stack traces, interactive debugging
• Methods on enum variants — a radius() method valid only for Shape.Circle, callable without a full match. Design questions include declaration syntax (qualified form vs. nesting), the meaning of self in a variant method (the variant's payload vs. the full enum), static vs. runtime type narrowing for wrong-variant calls, interaction with matches-based narrowing, and whether variant methods can satisfy interface requirements.
• Automatic interface derivation — compiler-generated implementations of mechanical interfaces (PartialEq, Eq, Hash, ToString, Comparable) from a struct's field declarations. Depends on an annotation or derivation syntax (e.g., @derive(Eq, Hash)). Design questions include which interfaces are derivable, field ordering for Comparable, conditional conformance for generic structs (Foo[T] derives Eq where T: Eq[T]), and whether an explicit implementation alongside a derived one is a compile error. Tied to the annotations feature below.
• Annotations and metaprogramming — structured metadata attachable to declarations (@deprecated, @inline, @derive(...)). A prerequisite for automatic derivation. Design questions include syntax (@name / @name(args)), which declaration kinds can be annotated, whether annotations are a closed compiler-defined set or user-extensible, compile-time vs. runtime visibility, and whether a full procedural macro system is in scope.
• Foreign function interface (FFI) — a mechanism for calling into code written in other languages with full type safety. Design questions include declaration file format (e.g., dedicated .d.leaf files vs. inline annotations), how foreign types and signatures are expressed, constant and mutable binding semantics, linking and runtime resolution strategy, and integration with the module system (use @pkg).

Last Updated: 2026-04-03