First Draft: Static Single Assignment

[Peter C]

On Tuesday, 18 November 2025 at 13:31:00 UTC, Quirin Schroll 
wrote:
>
>...

Consider this to be my complete rejection of further overloading 
the meaning of final in D.

The proposal to further overload 'final', to serve as the 
solutiuon for Single Assignment Annotation (SAA), and/or Foreign 
Function Interface (FFI) compatibility, would create an 
unnecessary semantic collision within the D programming language.

What is the semantic collision I'm concerned about?

D already uses final for structural constraints within the 
Object-Oriented paradigm, and in an orthogonal use, for control 
flow constraint on the switch statement.

Structural constraints within the Object-Oriented paradigm:
  - A class can be declared 'final' to prevent subclassing
  - A class method can be declared 'final' to prevent a derived 
class overriding it
  - Interfaces can define 'final' methods

Control Flow Constraint (Orthogonal Use)
  - A final switch (Exhaustiveness Check).

These two uses - inheritance policy and control flow 
exhaustiveness - have no logical or semantic connection, they are 
orthogonal to each other.

So currently, D developers must already mentally juggle 
orthogonal concepts under a single keyword.

Introducing a third, unrelated meaning for final, in relation to 
FFI/SAA, would cause a more severe semantic collision.

'final' should not be overloaded any further! That is final!

Recommended Alternative:

The optimal solution is to introduce a new contextual keyword -> 
'fixed' (which currently does not exist in D as an identifier, 
and so eliminates any semantic collision risk).

The compiler would treat 'fixed' as a keyword only in a specific 
type qualification context, meaning existing code that uses 
'fixed' as an identifier outside of that context would not break.

- using 'fixed' for SSA -
The concept of SAA is about declaring a variable whose binding is 
fixed after initialization. The keyword 'fixed' directly conveys 
this intent.
fixed(void delegate()) fixedIncrements = { counter++; }; // the 
variable fixedIncrements is an SAA

- using 'fixed' for FFI -
The concept of FFI (Foreign Function Interface) compatibility is 
about declaring a pointer's address as non-reassignable to 
correctly model the C/C++ type T* const. The keyword 'fixed' 
directly conveys this intent.
fixed(int)* // models the C++ type int* const

Other than C# (and F#) I'm not currently aware of any programming 
languages that use 'fixed'.

Assuming C# developers can handle this ambiguity, then it should 
be fine in D (I'm speaking as a C# programmer btw. and I would 
have no semantic confusion as to what 'fixed' would mean in D).

**If we settle on a new term, that would really help when 
providing your example code, and we can all see how well the new 
term would fit, or not fit.

At the moment, in my mind, final does not fit.

I had a similar problem with the term 'private(this)' in OpenD. I 
then changed it to 'scopeprivate' in my fork, and all of a sudden 
I felt completely comfortable using it.

I also have a problem using 'final' for anything other than what 
it currently means in D.