Types

Platform spec node

Types

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 the type grammar, nominal type declarations, and static rules shared by resolution, type checking, and lowering. Expression typing is completed in Type inference; dispatch in Method dispatch.

Type expressions

A type expression (BeskidType) must be exactly one of:

Form	Syntax	Meaning
Primitive	bool, i32, i64, u8, f64, char, string, unit	Builtin scalar types
Named	Path with optional GenericArguments	Nominal reference to type, enum, or generic parameter
Array	T[]	Homogeneous slice-like sequence; runtime ABI uses fat pointer layout
Reference	ref T	By-reference parameter passing surface (see memory chapter)
Function	T(params) or (params) => R	Function types for values and signatures

Primitives must map to HirPrimitiveType variants in the reference compiler.

Type declarations

• type Name<G…> : Contracts… { fields } introduces a nominal record-like type.
• Fields may be value fields (T name), event fields (see Events), or inject fields (composition only).
• Conformance list (: I, J) declares contract implementations checked in Contracts.
• enum declarations are specified in Enums and match.
• extend type adds members externally per extend type.

Static rules

• Duplicate type or member names in the same scope must error (E1001, E1006).
• Unknown types in definitions must error (E1005, E1201).
• Generic arity must match at use sites (E1203, E1204).
• unit is the statement-result type; never is the bottom type for non-returning calls.
• There is no null literal and no nullable reference type (?T, T?, or optional keyword) in v0.1.
• Optional presence must use Option<T> (Query.Contracts.Option in corelib) or an explicit enum with a dedicated absent variant at API boundaries.
• ref T in signatures denotes by-reference passing; it must not imply nullability or a separate reference/value type split.

Dynamic semantics

Types describe compile-time properties; runtime representation is defined by lowering and execution ABI. Array values must use the BeskidArray layout documented in execution ABI material.

Diagnostics

Type band E12xx (unknown type, mismatch, missing annotation, member access). Registry: Diagnostic code registry.

Conformance

L2 conforming implementations must reject programs with unknown types, arity mismatches, and invalid field access per the reference beskid_analysis type tests.

Decisions

• D-LM-TYP-001 — Nominal types: Beskid uses nominal, path-resolved types; structural equivalence is not user-definable in v0.1.
• D-LM-TYP-002 — Option<T> only: Optional values use Option<T> or explicit enums; null and optional keyword are forbidden.
• D-LM-TYP-003 — T[] fat pointer: Array types share one runtime representation across targets unless a profile documents otherwise.
• D-LM-TYP-004 — Single type system: No parallel reference/value kinds; ref is a passing mode, not a second class of types.

Platform view

The type grammar (nominal types, generics, ref T, Option<T>) is the backbone of static checking. All analysis phases share these definitions.