First Draft: Static Single Assignment

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Sat Dec 6 04:26:53 UTC 2025


I've been having a bit of trouble putting into words what I want to say 
here following more information gathered in this thread.

This is not a solution to the head const problems that made me want it 
in the past nor does it align with what I remember other people have had 
either.

My earlier excitement to this has now changed to: "why would we ever 
want something like this?". It is for all intents and purposes a worse 
const which is trying to solve a problem that does not exist.

The problem I and others have, is wanting interior mutability, with 
external immutability.

It is not a unique problem to D, other languages like Rust have a 
solution to it (keep in mind mutability is opt-in), via the Cell struct. 
https://doc.rust-lang.org/std/cell/struct.Cell.html

A solution you can do in Swift similarly: 
https://mcky.dev/blog/interior-mutability-swift/

What is desired is the opposite of Rebindable: 
https://dlang.org/phobos/std_typecons.html#Rebindable

So that:

1. A pointer may not be changed once set

2. The contents of an object pointed to from a pointer may be changed

3. Taking a pointer to that pointer won't compile or will be const(T*)

On the other hand this proposal is for all intents and purposes const 
except: You can copy it and it won't be const anymore.

As long as this does more than protect an exterior pointer, methods will 
need to have their this pointer marked as final or const to be callable.



More information about the dip.development mailing list