Type inference

Platform spec node

Type inference

Back to Type system ◎ 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

• Enums and match Algebraic enums and exhaustive `match` tie data representation to control flow. Lowering must preserve discriminant layout described in Execution where relevant. article Standard Reviewed Thu May 21
• Method dispatch Virtual dispatch, overload resolution, and receiver rules decide which code runs. Interop and codegen consume the same dispatch table model. article Standard Reviewed Thu May 21
• Type inference Local type inference reduces annotation burden while keeping programs predictable. The inference algorithm is specified here; diagnostics reference these rules. article Standard Reviewed Thu May 21
• Types The type grammar (nominal types, generics, ref T, Option T) is the backbone of static checking. All analysis phases share these definitions. 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
  Type system

  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 when types must be written explicitly and when the compiler may infer types from context. Ground rules for type expressions are in Types.

Inference sites

• let name = expr (inferred let) must infer the variable type from expr when unambiguous.
• let T name = expr (typed let) must check expr against T; no inference of T from the initializer alone.
• Function return types on top-level functions should be explicit; when omitted, inference may use body yield rules; explicit annotation is recommended for public APIs.
• Generic arguments at call sites may be inferred from parameter types when a unique solution exists (E1203 when missing).
• Lambda parameter types may be inferred from expected function type; untyped lambda parameters require contextual type (E1202 when missing).

Static rules

• Inference must not widen beyond the declared or inferred constraint (no implicit numeric promotion across unrelated primitives in v0.1).
• Ambiguous inference must error with E1202 (missing annotation) rather than pick an arbitrary type.
• Enum constructors and struct literals must have sufficient context to resolve the target type or require explicit qualification.

Dynamic semantics

Inference affects compile-time only; no runtime reflection of inferred types beyond debug metadata.

Diagnostics

E1202 missing annotation; E1206 mismatch after inference. Registry: Diagnostic code registry.

Conformance

Reference compiler tests for let inference and generic call inference must pass for L2 claims.

Decisions

• D-LM-INF-001 — Fail on ambiguity: Prefer errors over guessing when multiple types satisfy constraints.
• D-LM-INF-002 — Public API annotations: Exported functions should declare return types even when inference succeeds.
• D-LM-INF-003 — No nullable inference: Inference must not introduce nullable or optional types; use Option<T> explicitly.
• D-LM-INF-004 — Contextual lambdas: Untyped lambda parameters require an expected function type from the enclosing expression.

Platform view

Local type inference reduces annotation burden while keeping programs predictable. The inference algorithm is specified here; diagnostics reference these rules.