float init 0 request

[Mike Parker]

On Saturday, 22 August 2026 at 03:52:57 UTC, GB wrote:
> Post was deleted, talk about cherry picking. See: 
> https://lists.puremagic.com/pipermail/digitalmars-d/2026-August/348061.html

Looks like someone mistakenly flagged the post as AI spam. Here's 
the text of the post:

---

On Friday, 14 August 2026 at 05:57:55 UTC, ABrightLight wrote:
> Hello. I understand this subject's been discussed a number of 
> times before, but I'd like to throw in my reasoning for why it 
> would benefit us more for floats to initialize to 0 than NaN.
>
> 1. float is generally used for numeric computation (things like 
> NaN boxing are examples of uses outside of this) and as such 
> have similarity to the integer types (they will even implicitly 
> coerce mathematical operations to float). Since integers 
> default to 0, floats should too.
>
> 1a. It may be argued that integers only default to 0 because 
> there is no meaningful "null" value, but in my opinion this is 
> not convincing because I think that most people would opt for 
> them getting a reasonable default value right from the start 
> instead of being forced to `= 0;` It is very common to see loop 
> variables and other forms just say `int i;` or similar, and no 
> one is confused by this.
>
> 2. It is argued that since, like pointers that have `null` and 
> are default initialized to this, floats should also initialize 
> to its version of `null`. However this is a false equivalence 
> since the use of a null pointer is specified/standardized to 
> crash the program due to a concern for memory safety (it's not 
> even set to undefined behavior, a program halt must occur). The 
> same memory safety concern is not present for most operations 
> relying on floats, and the existence of NaN being left without 
> a crash [or even an exception thrown] is to cater to 
> performance. For cases where debugging by program halt is 
> required, most of the time the approach done is for a compiler 
> switch to allow throwing an exception instead of just halting 
> the program, since a stack trace is presumed to be desired.
>
> 3. I know that rikki's DFA implementation will be able to 
> detect when a `float x;` occurs without then being actually 
> initialized to something useful (keep up the great work 
> rikki!), but this particular feature is a special case that is 
> not exactly within scope. And the fact that this is even being 
> added as a special case should be a hint that leaving NaN as 
> the default init is much less useful than some 
> integer-compatible value like 0.
>
> P.S. This subject is a bit subjective (no pun intended) but 
> overall we'd likely see more user satisfaction from the float 
> init switch. And from what I could tell, it's been well 
> received by the OpenD folks, so there's already been a bit of a 
> testbed for this.

The debate is treating a symptom-management mechanism as though
it were an invariant-enforcement mechanism.

float.init == 0 vs float.init == NaN is somewhat of a distraction.

A sentinel value is not the same thing as an invariant.

The default value can absolutely affect how bugs manifest, but
you should not be relying on a language's default initialization
to establish a semantic invariant. The default value is
irrelevant to establishing that invariant.

Better to rely on the relationship between a value and the
meaning the next operation assumes it has.

That's the more fundamental issue here: not whether the default
value is 0 or NaN, but whether the value still means what the
operation consuming it assumes it means.

Interestingly, that is what this book, 'The Wrong Memory', is all
about. The dangerous bug isn't necessarily the wrong value, but
the moment when a value stops meaning what we think it means.

https://strawberry9.github.io/the-wrong-memory/cover.html