float init 0 request

[GB]

On Monday, 24 August 2026 at 20:53:50 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> On 24/08/2026 11:05 PM, GB wrote:
>> On Sunday, 23 August 2026 at 23:31:23 UTC, Richard (Rikki) 
>> Andrew Cattermole wrote:
>>> ..
>>> ...
>>> TLDR: what you are wanting isn't that hard to implement, but 
>>> is unlikely to be accepted by the D community.
>> 
>> It sounds like a potentially useful feature, but it's not 
>> really something 'I want'. I just offered it as a possible 
>> solution to those debating the issues in this thread.
>> 
>> As for Fast DFA:
>> 
>> As I understand it, the existing entry architecture 
>> intentionally separates analysis from reporting.
>> 
>> So the question would be how to get it to change the treatment 
>> of @mustAssign from "don't report" to "diagnose."
>> 
>> Most of the existing machinery needed seems to already be in 
>> place.
>> 
>> I expect with not to much work, the Fast DFA expression 
>> walker/reporter could easily be modified to handle @mustAssign 
>> (should the feature ever be seriously considered).
> I wouldn't implement it using an attribute, nor am I prepared 
> to merge it.
>
> Changing behavior based upon the variable and type isn't a good 
> idea, due to other modelling.
>
> Changing the behavior so that the writeOnVarAtThisPoint prefers 
> < 0 value, in meet/joinConsequence functions while possible, 
> would effect other parts of the engine and how they function.
>
> The way I designed and implemented the fast dfa engine is to 
> use as much of the information it can gather as possible, it 
> all works together, every analysis interacts with the others to 
> give the least amount of false positives as possible while 
> trying to get as much guarantees as possible. There is a lot of 
> interplay within it.

That doesn't stop others from trying ;-)

@mustAssign is really just a more generalized form of C# 11's 
required:

class Person
{
     public required string FirstName { get; init; }
     public required string LastName  { get; init; }
}

var p = new Person(); // compile-time error

// This is OK:
var p = new Person
{
     FirstName = "Ada",
     LastName = "Lovelace"
};


So 'required' is about expressing an obligation on the caller.

That's basically the same motivation behind @mustAssign.

In C#, the requirement is attached to the construction boundary.

With @mustAssign, the requirement is attached to the variable's 
data-flow lifetime.

That's where they differ, primarily.

The killer use case for both is making invalid omission 
impossible to overlook — at compile time.

But, as you point out, whether a @mustAssign implementation could 
integrate with D's existing definite-assignment/data-flow 
analysis is the interesting question.

Default initialization is useful mechanically, but it isn't 
always meaningful semantically.

A language that can express that distinction can catch a class of 
bugs that neither "everything must be initialized" nor 
"everything gets a safe default" handles particularly well.

Of course, it would be useful as a targeted annotation, rather 
than sprinkling it everywhere.

The strongest analogy isn't actually C#'s 'required'; it's things 
like assert, const, @safe, scope, etc.

Programmers already use those when the extra constraint 
communicates something important that the compiler otherwise 
cannot know.