Fixing C's Biggest Mistake

[cc]

On Sunday, 1 January 2023 at 20:04:13 UTC, Walter Bright wrote:
> On 12/31/2022 10:33 AM, monkyyy wrote:
>> When adr is making a video game on stream and defines a vec2 
>> with default initialized floats; it's a video game it should 
>> be fail-safe and init to 0 rather than have him take 10 
>> minutes on stage debugging it. Different situations can call 
>> for different solutions, why is safety within computer science 
>> universally without context?
>
> You're right that a video game need not care about correctness 
> or corruption.

I don't think that's a very apt take *at all*.  Frankly it's 
insulting.  You do realize video games are a *business*, right?  
They absolutely care about correctness and corruption.  On this 
specific issue, it so happens that developers also tend to find 
it very useful and common for numeric types to initialize to zero 
(when they are initialized at all).  Which is why they find it 
very *surprising* and *confusing* when they suddenly don't.  This 
should not be interpreted to mean that their industry is lazy and 
"doesn't care" about the financial viability of releasing sound 
code.

"If they really cared, they'd just initialize everything like 
they're supposed to" is not a well-aimed criticism coming from D 
(and the same argument applies to aviation; should they not 
initialize everything to NaN, just to be safe? Or do they not 
care?).  C++ requires initialization, because depending on 
compiler there's a good chance your program will just 
catastrophically explode otherwise.  Many other heavy lifting 
languages in the marketplace have adopted default/value 
initialization.  D, for some reason, has decided to free the 
programmer from worry by adopting usable default initialization, 
and then turn around and give you a value *you can't use*, for 
certain arbitrary extremely common primitive types, but not all 
variables, in order to satisfy what is, in some estimations, a 
minority use case, thus making things more difficult for the 
majority who might expect consistency, both internal and 
external.  D *almost* solves the first problem, then creates a 
new one.

Yes, I realize the NaN thing is an old dead horse and isn't going 
to change.  I had not intended to make any posts complaining 
about "D leadership" as I've at times witnessed in this thread 
and others, as I ordinarily have no direct problems with, 
engagement with, or influence over it.  But it's very troubling 
to suddenly see a mentality of "ah, who cares about those use 
cases?  They don't care about writing real programs, they're not 
flying airplanes!" coming from the top.

Developers are not just hobbyists.  There are careers, employees, 
and families in the mix.  $180 billion dollar industry.  Shigeru 
Miyamoto was not harmed by the fact Mario can clip through 
otherwise solid blocks due to mathematical insufficiencies in his 
1985 video game.  These days, a buggy mess means jobs are lost.  
Does D only ever see itself as a "hobby language" in this field 
then?  Should that be how we treat it?  I believe it has the 
potential to be much more, enough to the point I was willing to 
stake at least a portion of my livelihood on it.  I took a 
chance--and still am--because I believed the good parts of D are 
**so good**, *even in its current state*, it's worth the 
potential risks to grow alongside it, and so far it has been.  
Not every studio or developer can be in the position to incur 
this cost of what is in some ways a show of faith.  I don't want 
to see those risks expand and those years lead to an eventual 
dead end because the designers don't consider my career a 
respectable use of time or the language.