Skip to content

CEP-0024: Unchecked Indexing

Draft

Draft proposal for unsafe or explicitly unchecked indexing syntax or APIs. V1 indexing is checked according to the selected safety mode.

Summary

Catalyst should eventually decide whether source can request unchecked indexing explicitly.

V1 indexing and slicing remain ordinary checked language operations over arrays, slices, and contract-shaped collections. Optimization mode alone should not create a new source-level unchecked operation.

Example

Possible future shape:

fn sum_trusted(items: []const i32) i32 {
  var total = 0
  for i in 0..items.len() {
    total += items.unchecked_at(i)
  }
  return total
}

The proposal must decide whether unchecked access is a method, operator form, unsafe block capability, or another explicit spelling.

Motivation

Unchecked indexing can be useful in performance-critical inner loops after an invariant has already been proven. It is also an easy way to create memory safety bugs if it is invisible or too ergonomic.

The operation should be visibly sharp and should interact cleanly with safety modes, diagnostics, and codegen.

Proposed Direction

The proposal should cover:

  • source spelling for unchecked indexing;
  • whether it applies to arrays, slices, custom sequences, or all indexable values;
  • whether it is an unsafe operation or a normal sharp API;
  • diagnostics for obviously invalid indexes;
  • interaction with bounds-check elimination and optimizer proofs;
  • reflection or lint metadata for code audits.

V1 Compatibility

V1 does not include unchecked indexing syntax. Bounds behavior remains owned by the accepted array, slice, range, and indexing rules.