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