Lambdas and closures

Platform spec node

Lambdas and closures

Back to Evaluation ◎ Open in platform map

Spec standingStandard

Owner

Piotr Mikstacki pmikstacki@cybernomad.it

Submitter

Piotr Mikstacki pmikstacki@cybernomad.it

Current document

ADRs

No architecture decision records under adr/ for this feature yet. Standard features must publish at least one ADR or keep a ## Decisions summary on the hub.

Articles

• Control flow Conditionals, loops, and structured control transfer. Lowering to HIR/CLIF follows the evaluation order defined here. article Standard Reviewed Thu May 21
• Events Multicast events, subscription lifetime, and thread affinity assumptions. UI stacks build on these primitives. article Standard Reviewed Thu May 21
• Lambdas and closures Capture lists, environment layout, and lifetime of delegates. JIT and AOT must agree on closure calling conventions. article Standard Reviewed Thu May 21

History

0 revisions (git unavailable at build; counts may be empty)

Open full history on GitHub

No commits recorded for this path.

Completeness

OKarea · 2 SpecSection(s) · 0 H2 heading(s)

Section id	Required	Found
scope	yes	yes
features	yes	yes

Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).

Related spec docs

• Area
  Evaluation

  Parent area

• Domain
  Language meta

  Parent domain hub

• Domain
  Platform specification

  Cross-cutting index

• Domain
  Execution documentation

  Non-normative legacy execution bridge

Normative specification

Scope

Defines lambda expressions (=>), closures, and their typing. Function types are in Types; inference in Type inference.

Syntax

• param => body or (p1, p2) => body where body is an expression or { block }.
• Parameters may be typed (T name) or untyped (name) when contextual type is available.
• Lambdas may appear anywhere an Expression is allowed, including as spawn operands.

Static rules

• Lambda type must be inferable from expected type or parameter annotations (E1202 otherwise).
• Captured locals must be definitely assigned before capture or diagnosed per definite-assignment rules (v0.1: follow reference compiler behavior).
• Lambdas must not capture mut bindings unless the implementation explicitly allows it; otherwise must error.

Dynamic semantics

• A closure must extend the lifetime of captured storage to at least the closure value’s lifetime.
• Invocation uses the standard function call ABI for the target triple.
• Closures passed to spawn must be compatible with fiber entry signatures (see Fibers and spawn).

Diagnostics

Type inference and call mismatch bands E1202, E1205. Registry: Diagnostic code registry.

Conformance

Closure codegen tests must match between debug and release for the reference backend on each supported triple.

Decisions

• D-LM-LAM-001 — Expression lambdas: Statement lambdas use block bodies; no separate fn literal syntax in v0.1.
• D-LM-LAM-002 — No async lambdas: async/await are not closure modifiers; use spawn instead.
• D-LM-LAM-003 — Capture extends lifetime: Closures must keep captured locals alive for the closure value’s lifetime.
• D-LM-LAM-004 — GC for escaped captures: Captured reference-bearing values must be heap-traced when they escape the frame.

Platform view

Capture lists, environment layout, and lifetime of delegates. JIT and AOT must agree on closure calling conventions.