First Draft: Static Single Assignment

[Peter C]

On Thursday, 27 November 2025 at 19:41:18 UTC, Jonathan M Davis 
wrote:
>
> ..
> - Jonathan M Davis

The 'real' motivation seems clear to me: It's a proposal for a 
minimalist, pragmatic implementation of single-assignment 
semantics in D.

By minimialist, it means getting single-assignment semantics 
without fundamentally restructuring D's type system.

So final should remain a storage class. That final degrades to 
const in the presence of pointers/references, is the necessary 
tradeoff.

As for compound assignment, for a user defined type it is just 
syntactical sugar for a function call (opOpAssign), which is a 
form of mutation, not re-assignment.

Compound assignment on a primitive type suggests an intention to 
mutate, not reassign. So to maintain conceptual consistency, 
compound assignments should also be allowed on 'final' primitive 
types.

Cases where you need single-assignment and mutable primitive 
types (like int) are rare, and may well be considered a niche use 
case, but I disagree that overall this would be a 'niche' feature.

It is of course appropriate to do a thorough cost-benefit 
analysis of this feature, but I believe there are a sufficient 
number of cases for where a mutable, single-assignment variable 
would be very useful.