Method dispatch
Platform spec node
Method dispatch
Spec standingStandard
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.
- Enums and match Algebraic enums and exhaustive `match` tie data representation to control flow. Lowering must preserve discriminant layout described in Execution where relevant.
- Method dispatch Virtual dispatch, overload resolution, and receiver rules decide which code runs. Interop and codegen consume the same dispatch table model.
- Type inference Local type inference reduces annotation burden while keeping programs predictable. The inference algorithm is specified here; diagnostics reference these rules.
- Types The type grammar (nominal types, generics, ref T, Option T) is the backbone of static checking. All analysis phases share these definitions.
0 revisions (git unavailable at build; counts may be empty)
No commits recorded for this path.
| 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).
Normative specification
Section titled “Normative specification”Defines how member access (receiver.method(args)) and free functions resolve to callable targets. Type shapes come from Types; symbols from Name resolution.
Receivers and members
Section titled “Receivers and members”- Instance calls use postfix
.Identifierafter a primary expression that denotes a value type. - The receiver’s static type must expose a callable member with matching name and signature, or the call must error (E1101, E1213).
extend typemembers participate in the member set of the extended type with the same visibility rules as declared members.
Overload resolution (v0.1)
Section titled “Overload resolution (v0.1)”- Overloading must be resolved by arity and argument types at the call site; there is no ad hoc ranking beyond signature match.
- Ambiguous overload sets must error rather than pick a candidate.
- Contracts used as namespaces (
Contract.method()) follow resolver fallback for contract-as-namespace calls.
impl blocks
Section titled “impl blocks”- Legacy
impl Receiver { … }blocks may still parse; new code should useextend typeper extend type. - Methods in
impl/extend typemust obey visibility and access rules of the target type.
Dynamic semantics
Section titled “Dynamic semantics”- Dispatch is static in v0.1: the callee is known at compile time from the receiver’s static type (no virtual table polymorphism for user classes unless introduced by a future decision).
- Interop thunks must preserve the statically selected symbol through lowering.
Diagnostics
Section titled “Diagnostics”Resolution E1101; type/call E1204–E1205; invalid member E1213. Registry: Diagnostic code registry.
Conformance
Section titled “Conformance”Call resolution tests in beskid_analysis must pass for L2 claims.
Decisions
Section titled “Decisions”- D-LM-DISP-001 — Static dispatch default: v0.1 uses compile-time member selection; dynamic polymorphism is deferred.
- D-LM-DISP-002 — extend over impl:
extend typeis the normative extension syntax;implremains parse-compatible during migration. - D-LM-DISP-003 — Receiver static type: Dispatch keys off the static type of the receiver expression, not runtime tags.
- D-LM-DISP-004 — No
nullreceiver: Calls on possibly-absent values must useOption<T>andmatch, not null checks.
Platform view
Section titled “Platform view”Virtual dispatch, overload resolution, and receiver rules decide which code runs. Interop and codegen consume the same dispatch table model.