NaNs Just Don't Get No Respect

[Peter Alexander]

On Sunday, 19 August 2012 at 14:14:00 UTC, Michel Fortin wrote:
> On 2012-08-19 05:54:49 +0000, Walter Bright 
> <newshound2 at digitalmars.com> said:
>
>> On 8/18/2012 9:21 PM, Nick Sabalausky wrote:
>>> After actually *using* both D (default-initialization) and C#
>>> (statically/conservatively ensure things can't be accessed 
>>> without
>>> being explicitly inited), and I'm convinced the benefits of 
>>> the static
>>> checks easily outweigh the fear of a knee-jerk "=0".
>> 
>> I'm less willing to throw default initialization out - I like 
>> it & rely on it. The C# approach pretty much ends default 
>> initialization, including for user defined types.
>
> I like default initialization too, and I rely on it. By that I 
> mean that all the time I write "size_t count;" and assume it'll 
> be default initialized to zero. I like it because it's less 
> typing and it's simple: if I don't assign anything it's zero. I 
> can't do that for floats or chars, because the default 
> initialization gives me a unusable value. In my mind C#-style 
> conservative flow analysis errors are better than default 
> initialization to a bogus value because they catch the problem 
> at compile time. But on the other side I'd rather not give up 
> on integer default initialization to zero, as I actually prefer 
> this over everything else.
>
> So Walter, which default initialization do you like an rely on?
>
> As I said, personally, I'd have everything initialized to zero 
> by default. But at this point you can't really change this even 
> if you want to: some program somewhere might rely on float 
> being initialized to NaN by default and might start to give 
> erroneous results if you change the default. (Notice the irony?)

The problem with implicit initialisation to zero is that it is 
indistinguishable from simply forgetting to initialise the value.

There's three scenarios here:

1. You intentionally relied on implicit initialisation: GOOD.
2. You forgot, 0 wasn't what you wanted, but the error shows up 
quickly: NOT BAD
3. You forgot, 0 wasn't what you wanted, but the error is 
subtle/rare: BAD

#3 is where the nasty bugs come in. From my experience, these 
bugs have the potential to be monsters, and in my opinion, 
avoiding them is far more important than saving a couple of 
keystrokes in initialisation.

There's two solutions:

1. Conservative compile-time error on uninitialised variables.
2. Initialise to a value that will make scenario #2 more likely 
than scenario #3 (e.g. NaN)

Personally, I'd prefer option 1. Walter's argument is that this 
"leads to the programmer getting annoyed with false positive 
error diagnostics, and he'll likely add an =0", which is true, 
but in my opinion this scenario is quite rare to start with, and 
it's even more rare that 0 isn't actually the right 
initialisation value, and even then it's only a problem if the 
introduced bug is hard to reproduce. I find it more likely that 
the NaN will go unnoticed and cause rare bugs.