First Draft: Static Single Assignment

[Peter C]

On Saturday, 6 December 2025 at 04:26:53 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
>
> ..

The real problem is: the proposal for a 'storage-class' final is 
just a band-aid for local rebinding bugs. That is, it applies 
only to the specific binding in the scope where it's declared. 
That in itself can be very useful. But it doesn't deliver any 
systemic guarantees, because it's just lexical, not semantic. 
Once you copy or pass that reference around, the guarantee simply 
evaporates. Then you have to introduce this hack and that 
hack...and it gets messy pretty quickly.

Layering on hacks is not the solution.

For final to be useful beyond the scope in which it is declared, 
the guarantee must live in the type system, not just at the 
declaration site.

I propose:

(1) Adopt 'fixed' as a *contextual* keyword for single-assignment 
semantics.

(2) Make 'fixed' semantic, not just lexical: encode 
non-rebindability in the type itself, so the guarantee persists 
across copies and APIs.

Benefits:

  - Single-assignment binding: The variable is initialized once; 
rebinding is disallowed.

  - Reference identity guarantee: The handle's target identity 
remains stable; the object's internal state is orthogonal.

  - No decay on copy (if type-level): If 'fixed' is only a storage 
class, copies lose the guarantee. If 'fixed' is part of the type, 
the guarantee survives copies and API boundaries.

  - Head-const behavior (optional design): Taking pointers or 
references from a 'fixed' binding yields a head-const view (e.g., 
const(T*)), preventing mutable pointer-to-pointer leaks.

-- this is really how I want it to work --

public class Database { void bump() {} }

void main() {
     fixed Database db = new Database();
     db = new Database(); // Error: cannot modify `fixed db`

     auto copy = db; // fine. And copy is itself 'fixed'.
     copy = new Database();  // Error: cannot modify `fixed copy`

     db.bump(); // interior mutation still allowed
}