First Draft: Static Single Assignment

[Paul Backus]

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.