First Draft: Static Single Assignment

[Jonathan M Davis]

On Tuesday, December 2, 2025 4:04:27 PM Mountain Standard Time Paul Backus via dip.development wrote:
> If we are not willing to commit to making final a fully-fledged
> type qualifier, then I think we would be better off not including
> it in the language at all. If it's not worth doing right, it's
> not worth doing.

I agree with this 100%. What's proposed here seems like a mess of special
rules (with more likely to be added to deal with more complex situations),
and it's not going to interact well with user-defined types at all.

And if it's just useful for primitive types, what's that mean? That it makes
it possible to have a const pointer to mutable data or a mutable slice of
const data? I don't understand why that's useful enough to add a feature
like this, particularly if all it's really doing is making it so that a
programmer can catch when they assign a value to such a variable within a
function that's long enough that they can't catch it manually. IMHO, if the
function is long enough that that's an issue, then it's probably too long
and needs to be refactored.

Honestly, the more I look at the current state of things, the more I'm
inclined to think that storage classes in general are a mistake. And both
this proposal and DIP 1000 are examples of how trying to avoid a proper type
qualifier requires confusing special cases. I understand the desire to avoid
complicating the type system with more type qualifiers, but storage classes
largely seem to just end up being warts as a result.

- Jonathan M Davis