float init 0 request

[GB]

On Sunday, 23 August 2026 at 04:40:55 UTC, An wrote:
> On Saturday, 22 August 2026 at 23:49:35 UTC, claptrap wrote:
>> On Saturday, 22 August 2026 at 19:44:51 UTC, Walter Bright 
>> wrote:
>>> On 8/21/2026 4:22 PM, claptrap wrote:
>>>> My argument is that given that NaN doesnt guarantee you will 
>>>> get an obvious wrong value,
>>>
>
> Agree with you here.
>
> NaN -> wrong value -> time consuming to hunt for bug fix
> NaN -> wrong value -> no body read detail of spec/document
> NaN -> wrong value -> more compiler flag to work around bug fix
>
> 0.0 -> expected value most of the time -> work as expected
>
> If D want to fix, it should give a feature to extend 
> float/integer without needing a cast
>
> Not good/Limit
> struct ExtendedFloat
> {
>   float f;
>   alias this = f;
> }
>
> Something as below so that it does not need cast when assigned 
> from a float type
> ExtendedFloat extended of float
> {
>   invariant { value >= 2.0 && value <= 100.0 }
>   init => 10.0;
>   min => 2.0;
>   max => 100.0;
> }
>
> ExtendedFloat f1, f2; // default value to 10.0
> f1 = 1000.0; // invariant check - error/exception raised - out 
> of range
> f1 = f2; // no need for invariant check
> f1 = float.nan;  // invariant check - error/exception raised - 
> out of range

I think your ExtendedFloat idea is interesting, but I think it 
addresses a different part of the problem.

An invariant such as:

invariant { value >= 2.0 && value <= 100.0 }

answers the question "is this value valid for this type?"

What I'm interested in is an earlier question: "has the 
programmer explicitly established this value at all?"

The underlying problem in this thread, appears (at least to me) 
to be that the 'default value' is being asked to perform a job it 
cannot reliably perform.

int x;
produces:
physical state:
     storage exists
value state:
      x == int.init

It carry's no semantic state other than that.

I don't think this can be solved purely by making the value type 
richer.

It requires additional compiler knowledge:

physical state:
     storage exists

value state:
     x == int.init

semantic state:
     explicitlyAssigned == false

That is where @mustAssign comes in:

@mustAssign float f;
writeln(f); // error - even though f still contains a perfectly 
valid float.init.

The compiler needs to track a separate semantic state: whether 
the programmer has explicitly assigned the variable.

btw. I arrived at this idea after reading this book: 
https://strawberry9.github.io/the-wrong-memory/cover.html