float init 0 request

[claptrap]

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,
>
> Right, when you use NaN in a comparison. 0.0 used in a 
> comparison doesn't work any better at error detection, however.

Just accept at this point that nobody is ever claiming that zero 
init bugs are easier to detect than NaN init, so you dont need to 
repeat this.

The point is, is it worth turning a bunch of default inits into 
NaNs, to make them easier to detect, when zero init would mean 
most of them were not bugs to begin with.

It's a fuzzy question, is not clear how much harder erroneous 
zero inits are to find, nor is it clear how often NaN inits 
wouldn't be easily detected. Nor is it clear how often zero init 
would avoid it being a bug completely.

Acting like it's an obvious win is misguided.


>> and that zero init will likely reduce the total amount of 
>> errors,
>
> Better to reduce the errors to zero as much as practical.

Really?


> It is a fact that people mistakenly neglect to initialize a 
> variable. It is also true that 0.0 is more likely to be what 
> was intended than any other value.
>
> But that is not the point with NaN. The point is to make it 
> always the wrong value, and it is far, far, far more likely to 
> be detected than a wrong 0.0 initialization.

"far far far more likely" is doing a lot of work there.


>> Lets be honest, if zero init was such a source of bugs, it'd 
>> be an easy case to make because we'd all be so sick of hunting 
>> zero init integer bugs. But no one ever makes that point, 
>> because it's really a non issue.
>
> I've seen such errors, and while they don't occur often, they 
> can be hard to track down. I recall one that took a maddening 3 
> days to find.

I've had the same issue with NaNs, they were hidden due to int 
conversion.

But at the end of day this is just "design by anecdote".