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