Aliasing and mutability: which writes can affect a read?

Suppose a procedure first writes output = input + 1 and then writes output = output + input. With separate locations, the second input read obtains the original input. If input and output designate the same location in a language and API that permit this overlap, the first write also changes what the later input read sees. Trace each read and write in order before simplifying the expression. Treating the two names as independent values is an assumption that requires evidence from the interface or analysis.

The same problem appears in array kernels. An output slice can overlap an input slice partially, so advancing left to right may overwrite elements that later iterations still need. Some APIs explicitly support overlap through a temporary buffer or specified copy direction; others require disjoint regions. Do not infer one contract from a similarly named operation. For native numerical libraries, document whether in-place execution is allowed, which shapes and strides it permits, and whether two views can share storage despite having different starting addresses.

If a compiler can establish that writing one location cannot change another live input, it may reuse an earlier read in a register or simplify dependent operations. Violating a language's aliasing contract invalidates that reasoning, even when unoptimized machine code appeared to produce the result you expected. In safe Rust, the ordinary shared-reference and exclusive-mutable-reference rules prevent conflicting access patterns. The full unsafe aliasing model is subtle and evolving; avoid replacing it with the inaccurate slogan that two pointer values may never contain the same address.

Disjoint mutable subregions are a useful constructive example. A safe slice-splitting API can expose two mutable slices whose element ranges do not overlap. The caller can then update both without claiming that one entire array is simultaneously available through conflicting mutable views. This shifts the proof into a small, checked boundary. Raw pointers require additional reasoning: creating a raw pointer does not itself provide the lifetime, alignment, initialization, or access permission needed for dereferencing it. Address equality alone cannot settle all those questions.

Rust's UnsafeCell provides the primitive opt-out from the usual shared-reference immutability guarantee for its contents. It does not remove the exclusivity obligations of mutable references or permit data races. Higher-level wrappers add a discipline: a RefCell checks borrow rules dynamically in a single-threaded context, while an appropriate lock or atomic type supplies particular cross-thread guarantees. Choose the wrapper according to the required operation. An atomic field does not automatically make a multi-field invariant atomic, and a lock only protects readers and writers that actually follow its protocol.

The network lab makes a limited data-dependency connection. It computes σ(wx−0.5), with separate controls for input x and weight w. Set x=1 and w=1, inspect the product and output, then change w to 2 and predict that the output increases. The graph shows that a later read of a changed weight changes the function value. It contains no mutable pointers, overlapping slices, or compiler optimization. Explain which version of a weight an inference request should observe if another task updates a real model, and why a consistent snapshot requires a stronger design than merely storing each scalar safely.