On Tuesday, 23 August 2022 at 00:50:21 UTC, Walter Bright wrote:
> On 8/20/2022 3:17 PM, Dukc wrote:
>> it goes against what C, C++ and C# (and probably many other languages) do so one is easily surprised.
>
> C and C++ initialize them to garbage unless it is a global/static variable. That's probably the worst option, as it results in Heisenbugs that are very hard to track down.

Dont most C/C++ compilers have warnings for initialised variables? I'm sure MSVC did when I was using it, but its 15 years ago now.

On Tuesday, 23 August 2022 at 00:50:21 UTC, Walter Bright wrote:
> C and C++ initialize them to garbage unless it is a global/static variable. That's probably the worst option, as it results in Heisenbugs that are very hard to track down.

I agree that NaN for uninitialized floats is the best option.
However, can we get a switch to force initialization of floats? it would be of great help to quickly find the place where one forgot to initialize a variable.

On 8/23/22 01:07, IGotD- wrote:
> On Tuesday, 23 August 2022 at 01:19:35 UTC, Steven Schveighoffer wrote:
>>
>> Agreed that C/C++ initializing with garbage is the worst option.
>>
>> C# (as also mentioned) uses 0.
>>
>> I'm curious what all languages do that actually use an initial value?
>>
>> -Steve
>
> C++11 default value initialization exist. Meaning this
>
> ```c++
> double x{};
> ```

At that level, it's the same in D:

// Garbage value:
  double x = void;   // D
  double x;          // C++

// Zero value:
  double x = 0;      // D
  double x{};        // C++

However, there is a difference with members:

struct S {
  double x;
}  // Add ; here for C++

  S();   // S.x is double.nan in D
  S{};   // S.x is 0 in C++

> find a language other than D that default initializes
> floats to NaN.

I failed with a quick search.

However, I still think initial value being nan is not an issue even if it does not meet programmer expectations. For example, D could not leave the value as garbage as C++ programmers comfortably expect so. And I am pretty sure the default value cannot be changed for D at this time.

Ali

On 8/22/22 07:16, Steven Schveighoffer wrote:

> One thing that everyone seems to be ignoring is that 99% of the time,
> when I find out I didn't initialize a float and it's NaN, it's because I
> didn't correctly initialize it to 0.

Although Walter has already said it on this thread, what is missing in this picture is, 63% of the time we would not even know we had bugs if D picked the default value to be 0.0.[1]

I bet I can find bugs related to initialization in 12% of production C++ programs that use floating point variables.

Ali

[1] Yes, I made 63% up.

[2] I made that up as well but I am more confident in that figure. :o)

On Tuesday, 23 August 2022 at 15:27:05 UTC, Ali Çehreli wrote:
>
> However, I still think initial value being nan is not an issue even if it does not meet programmer expectations. For example, D could not leave the value as garbage as C++ programmers comfortably expect so. And I am pretty sure the default value cannot be changed for D at this time.
>
> Ali

It's too late for D2 but for D3 this should be taken into consideration. We are starting to acquire a big list of things that can be done for D3 now.

On Monday, 22 August 2022 at 14:16:14 UTC, Steven Schveighoffer wrote:
> Imagine you are making a 3-d model, and one vertex out of 100k is NaN. How will you notice it? A single missing triangle somewhere?
>
> But make that vertex 0, and all of a sudden your model has this weird triangle sticking out extending to the origin, and is completely obvious.
>
> -Steve

It could just as well be a very obvious hole, as easy to make out as that spike. Also that number may not end up being 0 so the spike may be very subtle.
If I wouldn't notice, i.e. neither visibly nor due to a performance impact, I probably wouldn't even start looking.
I've seen these spikes due to errors in hardware or operating it outside specifications (over clocking, under volting), too.
But the artifact needn't necessarily be a triangle. Could be a color or transparency channel.
A NaN value is incorrect - would you know the same if it's any real number ? Or would you have to ask the artist ?
Would you even notice ? It may be off by just 0.35 in the blue channel - the eye is very insensitive to blue. It may not be obvious because of color blindness, or the monitor isn't calibrated to the color space, or any amount of different reasons.
But someone else may notice and send a bug report and when you start investigating, a NaN will tell you the truth even if you can't visually see it yourself.

In shapes it may be more obvious but anything in art goes and NaN is still always wrong.
It's like a math professor asking their students to name the highest number they know and professor is going to provide a higher number. Next thing that happens is that someone calls "infinity" - infinity isn't a number.

Maybe the situation could be improved in that the compiler adds checks for NaN akin to bounds checking and throws a NaN_Error. This way the error could be caught even before sending wrong data to the GPU - or whatever API.