float init 0 request

[GB]

On Monday, 24 August 2026 at 09:39:10 UTC, Peter Jacobs wrote:
> On Monday, 24 August 2026 at 03:16:29 UTC, Valentino Giudice 
> wrote:
>> On Friday, 14 August 2026 at 05:57:55 UTC, ABrightLight wrote:
>>
>> I don't see why all other types are initialized to the most 
>> useful value, but floats are initialized to the most useless 
>> one.
>>
>
> I am going speak against this view and, instead, support 
> Walter's take.  I have had four decades of experience with 
> numerical calculations and working with reasonably large codes 
> built by small groups of people who have various levels of 
> experience (See the blog entry 
> https://blog.dlang.org/archive/2022/02/02/a-gas-dynamics-toolkit-in-d/ ).  I find that NaN is a particularly useful value for tracking down coding errors, just as Walter describes.

On Monday, 24 August 2026 at 09:39:10 UTC, Peter Jacobs wrote:
> On Monday, 24 August 2026 at 03:16:29 UTC, Valentino Giudice 
> wrote:
>> On Friday, 14 August 2026 at 05:57:55 UTC, ABrightLight wrote:
>>
>> I don't see why all other types are initialized to the most 
>> useful value, but floats are initialized to the most useless 
>> one.
>>
>
> I am going speak against this view and, instead, support 
> Walter's take.  I have had four decades of experience with 
> numerical calculations and working with reasonably large codes 
> built by small groups of people who have various levels of 
> experience (See the blog entry 
> https://blog.dlang.org/archive/2022/02/02/a-gas-dynamics-toolkit-in-d/ ).  I find that NaN is a particularly useful value for tracking down coding errors, just as Walter describes.

NaN is valuable as the default, because when you do use the 
default initialization of a floating-point value, accidental use 
is much more likely to be detected.

I think the argument is sound.

But NaN is *runtime* and specific to floats!

float x;

Now here, the compiler can't know whether I intended the default 
value or simply forgot to initialize it. But that is true for any 
type that you don't initialize.

int bufferSize;
allocate(bufferSize);

or:

int accountBalance;
charge(accountBalance);

Zero can be a perfectly valid value while still being the wrong 
value. Worse, it can propagate indefinitely through a calculation 
without providing any indication that it originated from an 
uninitialized variable.

A language-level @mustAssign could preserve ordinary default 
initialization while allowing the programmer to **opt into** 
compile-time intent verification.

float x;                  // use the type's default
float y = 0;              // explicitly initialize to zero
@mustAssign float z;      // opt into compile-time intent 
verification

Compile-time detection seems preferable to runtime detection to 
me.

It doesn't require a magic sentinel for every type.

@mustAssign would be a mechanism for expressing compile-time 
programmer intent.

There is no need for @mustAssign to supplant NaN as a runtime 
poison value. Both can exist just fine.

Instead of debating what the best runtime poison value for a 
float type should be, perhaps it would be more productive for a 
programmer to be able to say:

"I don't want a default value for this particular declaration. I 
want the compiler to require me to establish one before its value 
is used."

How can we achieve this?

float x = 0.0;            // simply expresses a value
@mustAssign float x;      // expresses an obligation

@mustAssign gives you a language-level assertion about 
initialization which is not the same as just expressing a value.

Whether such a feature is valuable to programmers is ultimately a 
matter of judgment, but I think it is worth distinguishing that 
question from whether NaN is a useful runtime poison value.