As someone coming from Java to use D, I find it myself quite annoying that float and double are initialized to nan.

This is really bad, it is hard to detect for newcomers, there is no flag by default to throw an exception when some operation on nan is done. It can be misleading if you're not paying a lot of attention to what you're doing.

What I suggest is what any sane people would: use 0 as the start for float and double. 0 is the most common sense as a starting point for everything, and, there are 2 options we could go:

1: Emit a compilation error that every variable must be initialized (I thought D were trying to avoid runtime errors)
2: 0 init all types, so, none is actually invalid before use

Even char took me as surprise to know it actually starts as 0xff, I lost a bit of time trying to find that bug because it is so common that variables init as zero.

Although the char is a bit different beast in terms of breaking change, I really can't see anyone actually depending that your float is being initialized with nan, so I really would like to know how much people agree with this idea. It is so common to stumble on that problem that it is starting to feel as a real mistake.

On Friday, 19 August 2022 at 13:42:58 UTC, Hipreme wrote:

That would be a disaster. If you're computing a product, 0 is horrible, and there's nothing to suggest you're doing something wrong. At least nan is going to tell you that you've screwed up. The reasonable fix is to either make it a compilation error (my preference) or an error when compiled with a particular flag.

On Friday, 19 August 2022 at 13:42:58 UTC, Hipreme wrote:

Question: Can the x86 be set to trap when an operation with NaN is detected?

On Friday, 19 August 2022 at 13:42:58 UTC, Hipreme wrote:

It's not a mistake, default initialization in D is not designed to be an initialization substitute, it's designed in a way that missing initialization is easily detectable but not UB. However, thruth is that this only works for character and floating point types.

Changing that design would require a DIP I think.

On 8/19/22 12:34 PM, Basile B. wrote:

This is true, it's not a mistake, it is on purpose. The original idea behind default values is to correct so many mistakes from C where values are not initialized but just "happen" to work until it doesn't. But practically, it is now used as de-facto initialization, it's just too convenient. In that mindset, floats defaulting to NaN are an outlier.

However, in my recent efforts to port a decently sized C library to D, one thing I don't have a good answer for is code like:

ReallyLargeStruct foo = { 0 };

There just is no equivalent in D. In order to set all fields to 0, I would have to specify a complete layout of the entire thing. This could probably be done via introspection. But I just don't like it even in that case.

The easier thing to do is to default the float and double fields to 0 in the type definition, and then use default initialization to achieve the same. So I think in some cases, it's much nicer to just rely on the default initialization.

I also would prefer that all floats/doubles default to 0 instead of NaN.

-Steve

On Friday, 19 August 2022 at 17:14:35 UTC, Steven Schveighoffer wrote:

It would be awful to choose an arbitrary, often incorrect value in order to give the appearance that your program is running.

It would be absurd to silently set the value of z to 1.0 in this code:

double w;
double z = w*2.5 + 1;

Defaulting to 0 is no better than defaulting to a random number.

On Friday, 19 August 2022 at 16:34:59 UTC, Basile B. wrote:

Well, it is used as initialization substitute, if wasn't meant to be a substitute, not initializing a variable should be a compilation error. There's a lot of developers which uses bool and int because they make sense, when dealing with floating point they forget about that they do not make sense. I've never had any problem with float defaulting to 0 on Java. If the error happens, I get at max division by 0 exception. NaN does not cause this exception which actually makes the bug harder to find.

On 8/19/22 2:04 PM, bachmeier wrote:

The problem is that most people declare a number like int x and expect it to default to 0. Because that's what D does.

For a float (number), they expect the same thing.

But it defaults to a completely useless value (NaN). This is unexpected, and commonly leads to hours of head-scratching (see Adam's Ruppe's 2020 live coding session, where he couldn't figure out for much of the stream why his game wasn't working).

double w;
double z = w*2.5 + 1;

Not absurd at all. if w defaults to 0, I would expect z to be 2.5 * 0 + 1.

Change it to int, and see if it looks absurd to you. You just aren't used to it.

D used default values to prevent errors in not initializing values, but default initialization to a very commonly-expected value turns to be incredibly useful.

The design choices for float/double were made based on the fact that a value that means "this isn't initialized" existed. It didn't for int, so meh, 0 was chosen. Walter could have easily have just chosen int.min or something, and then we would possibly not ever be used to it. But now we are used to it, so it has become irksome that doubles/floats are the outlier here.

-Steve