First Draft: Static Single Assignment

[Meta]

On Friday, 28 November 2025 at 03:25:27 UTC, Paul Backus wrote:
> On Sunday, 16 November 2025 at 01:50:16 UTC, Walter Bright 
> wrote:
>> On 11/14/2025 11:13 PM, Walter Bright wrote:
>>> https://www.digitalmars.com/d/archives/digitalmars/dip/ideas/Single_Assignment_1765.html
>>
>> Ooops! forgot the linky:
>>
>> https://github.com/WalterBright/documents/blob/master/final.md
>
> Take these two rules:
>
>> A `ref` cannot be taken of a `final` declaration
>
>> `final` can be applied to function parameters, but overloading 
>> is not affected. Hence, it has no effect on name mangling.
>
> Now, consider their effect on the following code:
>
>     void foo(ref int n) {}
>     void foo(ref const int n) {}
>
>     void bar(ref inout int n) {}
>
>     void baz(T)(auto ref T t) {}
>
>     void main()
>     {
>         final int n;
>         foo(n); // Error - selects non-const overload
>         bar(n); // Error - substitutes mutable for inout
>         baz(n); // Error - calls baz!int(ref int)
>     }
>
> In all of these cases, the function calls *could* be made to 
> work. But because `final` is a storage class, not a type 
> qualifier, it cannot participate in overload selection, `inout` 
> substitution, or template instantiation, and the compiler 
> cannot figure out how to call the function correctly.
>
> It is worth noting that all three calls would succeed if 
> `final` were replaced with `const`.
>
> If `final` is implemented as proposed, these kinds of edge 
> cases will severely hinder its adoption.

Ya, it introduces all sorts of complications. Hence my suggestion 
to take the simpler route and allow final variables to be 
modified through references and pointers. But at that point it 
just becomes a lint and there's very little benefit.