Static struct initialization syntax behavior & it being disabled upon adding a constructor

[cc]

On Monday, 18 April 2022 at 10:26:16 UTC, HuskyNator wrote:
> On a sidenote, I'm surprised D did not choose 0 as the default 
> floating value. Doesn't almost every language do this? I 
> understand the thinking behind it, but when the type one uses 
> in a template influences the behavior of the code, that seems 
> like a pretty big red flag to me. (Any non-floating type 
> defaults to 0, but using floats/doubles suddenly introduces 
> NaN, surely I'm not the only one that sees a problem with this 
> 😅) Especially when it's basically a standard 0 is used for 
> this. Sorry for the rant.

I agree, it's a hiccup.  I have at times intentionally 
initialized a float as NaN so that I can identify later whether 
an appropriate value has been assigned, but I've never seen the 
need to have this be the default behavior when integer types 
always init to 0 (more specifically, init to a MODIFYABLE value). 
  In game design I have tons upon tons of floats that all [should] 
start initialized to zero.  I can add 4 to a declared but 
not-assigned-to int and it'll be 4, a float remains NaN.  Having 
to manually declare appropriate init values to each one doesn't 
aid me in detecting "bugs".  If I had an int that was supposed to 
default to 10 instead of 0 it would still be a bug if I forgot to 
specify that, tripping me up for falsely assuming floats would 
start at 0 doesn't aid my workflow in any way.  The whole "you 
should pay more attention to what you're initializing, o buggy 
programmer you" philosophy seems like something that should be 
reserved for pointers and reference types, not basic numeric 
data.  It's probably set in stone by this point though and too 
late to change.

Ten years ago, almost to the day:
https://forum.dlang.org/thread/thsjtreegdwcgbazhczd@forum.dlang.org

The reasoning still feels flimsy and stubborn.