float init 0 request

[Richard (Rikki) Andrew Cattermole]

On 23/08/2026 11:17 PM, GB wrote:
> On Sunday, 23 August 2026 at 10:09:28 UTC, Nick Treleaven wrote:
>> On Sunday, 23 August 2026 at 00:53:31 UTC, GB wrote:
>>> D already has:
>>> - storage exists
>>> - default value exists
>>>
>>> If the compiler had access to more information:
>>> compiler knowledge -> explicitlyAssigned = false
>>> compiler knowledge -> explicitlyAssigned = true
>>>
>>> Then the following would be possible:
>>>
>>> @UNASSIGNED float f; // compiler knows -> explicitlyAssigned = false
>>> writeln(f);  // ERROR: @UNASSIGNED f has not been is explicitly 
>>> assigned.
>>
>> https://dlang.org/changelog/2.113.0.html#dmd.fastdfa.uninitialized
>>
>> It depends on if the compiler can prove that `f` is still 
>> uninitialized, which it can't always.
> 
> If only all problems were this easy to solve.

What the fast dfa engine does is not at all easy to replicate.
For its requirements it may as well be state of the art.

> @mustAssign float f;
> 
> Note, it doesn't need to prove that f is uninitialized. It needs to 
> prove that f is definitely assigned. If it can't prove that, reject the 
> use.

It can, but its configured not to do this.

> conservatism is acceptable -> inability to prove assignment produces an 
> error.
> 
> Problem solved!
> 
> The harder part of this idea is how to establish precise rules for 
> control flow, function calls, ref/out, and aggregates; those edge cases 
> are where the idea will either become workable or fall apart.

The primary requirement of the fast dfa engine is to not produce false 
positives. All guarantees it can offer beyond that is really a bonus.

The second requirement is for it to be fast, and it is allowed to 
sacrifice guarantees to archive these requirements.

The two biggest problems is loopy labels, specifically switches that use 
goto case, and loops.

Interprocedural analysis is kept quite limited due to dmd's architecture 
not supporting interprocedural analysis. Everywhere it exists in D in 
the form of effects such as scope/return, pure, @nogc ext. all have 
problems to the effect of people referring to them as "attribute soup". 
If the compiler was capable of doing interprocedural analysis for 
effects this would have been solvable.

Function pointers are not currently supported, and neither are 
aggregates. Aggregates cannot be fully analyzed due to interprocedural 
analysis. Attributes will only ever cover the outer most cell in D.

Requiring attributes for features like float's and by-ref parameters is 
unacceptable for D's community as a whole. Lessons have been learned 
from the experiences of DIP1000, it is not moving forward because it 
does not align in practice with what the D community needs. It suffers 
from the compiler architecture problems as above.

TLDR: what you are wanting isn't that hard to implement, but is unlikely 
to be accepted by the D community.