First Draft: Static Single Assignment

[Paul Backus]

On Friday, 5 December 2025 at 01:18:44 UTC, Walter Bright wrote:
> On 12/2/2025 3:04 PM, Paul Backus wrote:
>> However, I do not think the best solution to that problem is 
>> to implement it in this strange, halfway-in-between state, 
>> where it's technically a storage class but sometimes *behaves* 
>> like a type qualifier.
>
> It does what it says on the cereal box it does - you cannot 
> change the value of a final declaration once it is initialized.
>
> The complications come from taking the address of a final 
> variable. I doubt this will be a common usage pattern. I 
> suppose we could delete that behavior, but I want to see first 
> if we can use it productively.

Well, no, the complications come as soon as you try to pass it to 
a function, as I explained in my earlier message:

https://forum.dlang.org/post/fpgcyzteuikxblkuwxkd@forum.dlang.org

Functions that overload on `ref` and `const ref` are a common 
usage pattern. Functions with an `inout ref` parameter are a 
common usage pattern. Template functions with an `auto ref T` 
parameter are a common usage pattern.

If we are not willing or able to implement `final` in a way that 
supports these usage patterns, then we would be better off 
without it.