XIOMPRIOR ART AND TRADE-OFFS

This page is documentation, not specification. It does not define XIOM; the normative definition is the Language Specification, Revision 0.3. Comparisons describe documented behavior at the time of writing, cover only the aspects named, and do not imply that any language is inferior. Where a capability is planned rather than shipped, it is labelled.

Design by Contract is prior art, not a new idea

Contracts in a programming language are a fifty-year-old idea with a strong lineage. Each project below solved a real problem, and XIOM reuses what it learned.

What XIOM takes from this lineage is the core claim behind it: a function's preconditions and postconditions belong in the language, where tools can read them. The bet XIOM adds is packaging and context -- an ownership-based systems language in which contracts are ordinary compiler input, runtime checks are on by default, and the toolchain is built for AI-assisted development.

Rust's lifetime system vs XIOM second-class references

Both languages use ownership and borrowing instead of a garbage collector. Rust spends more machinery in the type system to make borrowing broadly expressive; XIOM deliberately does less.

Aspect	Rust	XIOM
Borrow checking	Borrow checker with lifetimes and non-lexical lifetimes	Lexical scope borrowing -- validity follows scope nesting
Lifetime annotations	Required for non-trivial cases	None in source
Borrow stored in a struct field	Allowed with lifetime parameters	Not allowed
Borrow returned from a function	Allowed with lifetime parameters	Not allowed
Zero-copy patterns	Borrowed views, iterators and adapters	Owned values; handles, indices or arenas for scope-crossing designs
Where the complexity sits	In signatures and type annotations	In the design of APIs that need escaping borrows

In XIOM a reference is second-class: it cannot be returned from a function or stored in a struct field. This is a deliberate limitation, and it is the price of the simpler rule set. A borrow's life is visible by looking at the braces, and there are no lifetime parameters to thread through types. Patterns that depend on a borrow outliving its scope are expressed with owned values instead -- often a handle or index into an owning collection, or an arena -- and duplicating a value is always an explicit .clone().

This is not parity with Rust, and the site does not claim it. It is a different point in the design space, chosen to keep the language's rule surface small for humans and for AI-generated code. Data races are addressed separately: Send and Sync are enforced at compile time, including on values captured by spawn.

fn inspect(items: &Vec[Int]) { }   // borrow -- caller keeps ownership

fn build() -> Vec[Int] {
    var items = Vec.new();
    items.push(1);
    return items;                    // owned value, never a borrow
}

The full memory model documents the rules and the patterns that replace escaping borrows.

What runtime contracts cost

XIOM contracts are enforced at runtime by default. requires:, ensures: and invariant: compile to guards that trap on violation with a structured diagnostic naming the clause, function and line. Guards are checks, so they cost something on every execution of a checked path; the project does not quote overhead percentages it has not measured publicly.

Mechanism	Cost model	When it applies
Runtime guard (default)	A check on each call or return, and after mutations covered by an invariant	Default for every contract unless the checks are explicitly stripped
Release builds	Checks removed unless --runtime-contracts is passed	--release, or --no-contracts to strip them explicitly
Static proof	A proven obligation does not need a runtime guard; today the guard remains the default enforcement, and the verification path reports which obligations qualify	Supported properties, via the export, check and prove stages described below

The verification path is separate from the runtime path and is reported in three stages: --verify exports SMT-LIB proof obligations and makes no proof claim; xiom-verify --check checks that output with the bundled z3 and returns Proven, Violated or UNKNOWN; only unsat counts as proved. Obligations the encoder cannot express faithfully are reported UNKNOWN and never count as proofs. A contract in the source is not by itself a proof that it always holds -- the verdict is what carries weight, and it is labelled.

Compiling contract checks out of production builds is standard practice in this design space: Eiffel assertion monitoring can be disabled, and Ada assertion policies can turn checks off. The static route is the other answer, and it is the one SPARK and Dafny are built around. XIOM keeps runtime guards as the default, makes their removal an explicit flag, and treats proof as something to be earned per obligation rather than assumed.

No performance numbers are published on this page. The project runs a reproducible Docker benchmark that records builds with contracts enabled and disabled, generated source, compiler output, runtime results, token usage and complete sessions. Results will be published together with the harness so anyone can rerun them; see the note on the Why page.

What this page does not claim

• It is not an exhaustive survey of prior work -- it names the projects that most directly shaped XIOM's design and omits many others.
• It is not a benchmark. It contains no measured overhead numbers, and none should be inferred from the cost model above.
• It is not a claim that contracts make a program correct. Contracts describe intent; enforcement and proof cover supported properties only.
• It is not normative. Where this page and the specification disagree, the specification wins.