First Draft: Static Single Assignment

[Richard (Rikki) Andrew Cattermole]

On 03/12/2025 9:31 PM, Walter Bright wrote:
> On 11/27/2025 11:41 AM, Jonathan M Davis wrote:
>> Of course, that also leaves the question of "op assignment"
> 
> They're disallowed for `final` declarations.
> 
>> final int i = 42;
>> i += 10;
>>
>> should be legal,
> 
> I'm sorry, but the point is to make that illegal.
> 
> 
>> Of course, the other issue here is that because final is a storage 
>> class and
>> not a type qualifier, things are going to degrade to const pretty quickly
>> with pointers and references. For instance,
>>
>> final int i = 42;
>> auto ptr = &i;
>>
>> is going to have to make ptr const(int)* or const(int*)
> 
> or simply disallowed. I hadn't thought of that case, though there are 
> surely more cases I didn't think of!

That'll already be the case for @safe functions, but it shouldn't be 
disallowed for @system.

Typing it as const, also solves for fields.

```d
struct Foo {
	final int* field;
}

struct Bar {
	int* field;
}

Foo foo;
final Bar* bar;
Bar zar;
final Bar har;


&foo.field; // const(int**)
&bar.field; // int**
&zar.field; // int**
&har.field; // int**
```

I think I understand what we're miscommunicating on.

Me and JMD are thinking its about changing of slots, not values or 
objects contained within.

This weaker version isn't just a replication of const, that prevents 
method calls and other normal things. It'll be far more useful I suspect.