Contracts

Platform spec node

Contracts

Back to Contracts and effects ◎ 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

• Contracts Structural contract declarations, conformance lists, and embedding. Distinct from compiler Mod SDK contracts and from runtime requires/ensures (not in v0.1 grammar). article Standard Reviewed Thu May 21
• Error handling Representing and propagating failures (`Result`, `try`, unwinding policy). Runtime lowering shares the ABI error envelope described in Execution. article Standard Reviewed Thu May 21
• Testing The language-level test harness, discovery, and assertions users rely on. Corelib testing helpers extend but do not redefine these semantics. 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
  Contracts and effects

  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 contract declarations — structural interfaces that types implement via conformance lists. This is distinct from compiler Mod contracts (Compiler Mod SDK).

Syntax

contract Disposable
{
    unit Dispose();
}

• contract Name { items } declares required members.
• Items may be method signatures (T name(params);) or embeddings (OtherContract;) that flatten member requirements.
• Types declare implementation with type T : I, J { … }.

Static rules

• Implementing types must supply every required member with compatible signature (E1601, E1602, E1606).
• Conflicting embedded contract methods must error (E1004).
• Duplicate contract method names in one contract must error (E1003).
• Invalid conformance targets must error (E1607).

Dynamic semantics

• Contract calls use static dispatch on the receiver’s type after conformance is proven.
• Contracts may be used as namespaces for static-style calls when the resolver provides contract-as-namespace fallback.

Diagnostics

Contract band E1601–E1607. Registry: Diagnostic code registry.

Conformance

All Standard types advertising conformance must pass contract satisfaction in the reference compiler.

Decisions

• D-LM-CON-001 — Structural contracts: Beskid contracts are nominal surfaces checked structurally, not runtime interface tables in v0.1.
• D-LM-CON-002 — Embedding: Contract embedding composes requirements without inheritance syntax.
• D-LM-CON-003 — No requires/ensures in v0.1: Design-by-contract assertions are deferred; contract items are interface shapes only.
• D-LM-CON-004 — Distinct from Mod SDK: Compiler mod contract placements follow Compiler Mod SDK, not this user-language surface.

Platform view

Structural contract declarations and type conformance lists. Compiler mods and optional future runtime contract checks are specified elsewhere.