First Draft: Static Single Assignment

[Peter C]

On Saturday, 6 December 2025 at 07:49:18 UTC, Jonathan M Davis 
wrote:
> On Friday, December 5, 2025 8:37:00 PM Mountain Standard Time 
> Peter C via dip.development wrote:
>> On Saturday, 6 December 2025 at 00:51:37 UTC, Walter Bright 
>> wrote:
>> > On 12/5/2025 3:19 PM, Peter C wrote:
>> >> If the compiler counts default initialization as an 
>> >> assignment,
>> >
>> > It does!
>> >
>> >> then I've already 'used up' my one assignment before I even 
>> >> touch the variable!
>> >
>> > Oh well!
>>
>> Only assignment uses the assignment operator -> '='!
>>
>> If there is no assignment operator involved, then it cannot 
>> reasonably be counted as an assignment!
>>
>> int x; // this is NOT assignment!
>
> Well, if we want to get technical, talking about "static single 
> assignment" is kind of nonsensical considering what assignment 
> means in most languages - and certainly with what it means in 
> D. The initial value that a variable has comes from 
> initialization or construction, not assignment. Code such as
>
> int x = 42;
>
> involves no assignment whatsoever. It's initialization, not 
> assignment. Assignment is only used when a variable is given a 
> new value. For instance,
>
> T t = 42;
>
> would not use T's assignment operator if T overloaded the 
> assignment operator. Rather, it would use T's constructor, 
> because the code is equivalent to
>
> T t = T(42);
>
> In order to trigger assignment, = would have to be used outside 
> a variable declaration with code such as
>
> t = 42;
>
> rather than
>
> T t = 42;
>
> Similarly, assignment is _never_ legal with a const variable, 
> because that would mean mutating the variable, whereas 
> initialization is perfectly legal, because that's giving the 
> variable its initial value.
>
> So, what this final proposal is doing is actually saying that a 
> final variable can be initialized but it can never be assigned 
> to and not actually that it can be assigned to only once. The 
> critical difference from const is then that final is head-const 
> rather than full, transitive const.
>
> - Jonathan M Davis

Then I stand corrected.

int x = 42; // constructs a variable with an initial value - not 
considered an assignment.
x = 100; // performs the first 'assignment' operation.

final x = 42; // a final must be initialized with a value at the 
time of construction.
x = 100; // Error

In any case, without 'final' (of preferably 'fixed') being a part 
of the type system, it's just going to involve hack after hack to 
make it a useful addition to the D language. It'll get ugly. 
People won't like the hacks. There'll be a call to make it part 
of the type system itself. That'll be rejected because.. you 
know.. D is too complex already.. and all that. So.... 100 posts 
into this already, and nobody seems too enthusiastic about it.. 
most of us are still confused as to what it can or can't do, or 
what it will or won't do....

so.. no.. person(s) responsible should provide a better DIP next 
time, so we don't have to waste all this mental effort that 
should have been wasted by the person(s) drafting the DIP!