CEP-0010: Aliasing and Exclusivity Annotations¶

Summary¶

Catalyst should eventually decide whether source can state aliasing and exclusivity promises that the compiler may lower to backend metadata.

V1 keeps backend metadata conservative. Ordinary *T, *const T, and []T parameters do not imply no-alias or exclusivity guarantees.

Example¶

Possible future shape:

fn mix(noalias input: []const f32, noalias output: []mut f32) {
  for i in 0..input.len() {
    output[i] = input[i] * 0.5
  }
}

The proposal must decide whether promises attach to parameters, regions, call sites, or a different construct.

Motivation¶

Performance-sensitive code sometimes needs to promise that two memory regions do not overlap. This can enable vectorization, better C lowering, or stricter diagnostics. It is also a sharp promise: an incorrect annotation can make generated code wrong.

Aliasing annotations need a focused design so they remain honest, visible, and useful to both tooling and codegen.

Proposed Direction¶

The future design should cover:

• explicit noalias or exclusivity annotations;
• whether annotations apply to parameters, fields, local borrows, regions, or call sites;
• lowering to C restrict, LLVM noalias, or equivalent backend metadata;
• diagnostics when source obviously violates an exclusivity promise;
• interaction with slices, pointers, dynamic dispatch, resource disposal, and hidden temporaries;
• reflection or IR metadata needed by tools and backends.

V1 Compatibility¶

V1 emits no aliasing metadata for ordinary pointers and slices unless a separate accepted rule requires it. Checked realtime/no-allocation regions are tracked separately by CEP-0020.

Related Details¶

• Reference and Mutability
• Performance Model
• CEP-0020: Realtime Enforcement Regions