References And Unsafe

References And Unsafe

Reference syntax is explicit. &value forms a shared reference, &mut value forms a mutable reference shape, and *reference dereferences it.

fn read(value: &Int) -> Int {
  *value
}

The checker verifies reference and dereference shape and applies compiler-controlled Copy eligibility. These implemented checks are narrower than a complete ownership system.

Present ownership boundary

The current compiler does not enforce:

• borrow exclusivity;
• the mutability authority required to form every &mut reference;
• move state and use-after-move rejection;
• lifetime relationships;
• deterministic destruction or drop order.

The syntax is therefore a foundation for the intended model, not evidence that all programs accepted today satisfy Rust-style ownership guarantees. The interpreter also has no native address or layout contract.

Unsafe declarations and regions

Unsafe functions declare the capabilities their operations require. A caller grants capabilities with a lexically visible region.

unsafe(raw) {
  operationRequiringRawCapability()
}

Named capabilities are raw, foreign, unchecked, and null. A named region grants only its listed capabilities. A bare unsafe region grants the blanket set. Ordinary type checking remains active inside the region; unsafe is not a directive to ignore types.

For a direct call to a named unsafe function, the checker verifies that the surrounding region grants the required capabilities. An unused explicit grant is reported, keeping the declared exception close to an operation that justifies it.

Higher-order boundary

Function types do not retain unsafe or capability metadata. If an unsafe function is first stored in an ordinary function value, the later indirect call is not rejected by the current direct-name check. Qualified and aliased call forms share this incomplete boundary.

This is a known static-safety gap. Capability-bearing function types and transitive enforcement must close it before the feature can support a general safety claim.

What unsafe does not provide yet

Unsafe regions do not imply that the following exist:

• raw-pointer types and pointer arithmetic;
• stable foreign declaration syntax;
• ABI and native data-layout guarantees;
• native lowering or an FFI runtime;
• proof that safe code cannot reach an unsafe operation indirectly.

Use the current capability surface only as documented by the checker and interpreter. Do not write portability or memory-safety claims against planned backend behavior.

Related

• Types And Inference
• Compile-Time Evaluation
• Implementation Status