First Draft: Static Single Assignment

Peter C peterc at gmail.com
Fri Nov 21 08:10:31 UTC 2025


On Thursday, 20 November 2025 at 06:03:03 UTC, Walter Bright 
wrote:
>
> ...
> 2. Fields
>
> Problematic, because one can modify it with some pointer 
> manipulation
>
>

If you step outside the safety fence, then the problem is you, 
not the safety fence.

i.e.

With pointer manipulation (pointer bypass), the SAA rule is not 
broken. Rather its enforcement mechanism is circumvented by using 
a feature (a pointer) that operates at a lower level than the SAA 
contract is designed to monitor. The SAA feature itself, still 
would remain highly valuable here, for preventing accidental 
errors in safe code.

The fact that a dedicated, unsafe operation can bypass a safety 
check doesn't make the check problematic.

Accidental errors are a far more common and insidious problem 
than deliberate, unsafe memory operations.

High-level operation using the variable name (this.field = 
newValue;) // inside the fence
  - SAA successfully blocks the high-level reassignment with a 
compile-time error.

Low-level operation using memory addresses (*ptr_to_field = 
newAddress;). // outside the fence
  - The unsafe code circumvents the compiler's SAA check entirely.





More information about the dip.development mailing list