Why were uninitialized floating-point variables changed to quiet NaN's in v2.087?

[FinalEvilution]

I was looking at the docs for std.math.hardware's 
[FloatingPointControl](https://dlang.org/phobos/std_math_hardware.html#.FloatingPointControl) and i found the following lines
and example interesting.

> "Note in particular that if invalidException is enabled, a 
> hardware trap will be generated whenever an
uninitialized floating-point variable is used."

```
{
     FloatingPointControl fpctrl;

     // Enable hardware exceptions for division by zero, overflow 
to infinity,
     // invalid operations, and uninitialized floating-point 
variables.
     
fpctrl.enableExceptions(FloatingPointControl.severeExceptions);

     // This will generate a hardware exception, if x is a
     // default-initialized floating point variable:
     real x; // Add `= 0` or even `= real.nan` to not throw the 
exception.
     real y = x * 3.0;

     // The exception is only thrown for default-uninitialized 
NaN-s.
     // NaN-s with other payload are valid:
     real z = y * real.nan; // ok

     // The set hardware exceptions and rounding modes will be 
disabled when
     // leaving this scope.
}
```

This seems nice. Turn on fp exceptions in your main for debug 
builds and if it crashes use gdb
to get the stack trace.

But the example doesn't work.

Looking at the [dmd Change 
Log](https://dlang.org/changelog/2.087.0.html#nan) uninitialized 
float's were changed from
signaling NaN's to quiet NaN's in v2.087.0
I looked at the 
[issue](https://bugzilla-archive.dlang.org/bugs/19905/) and it's 
[see 
also](https://github.com/dlang/dmd/pull/7568#discussion_r159847869) but i don't understand what the harm would be
even if it's not 100% reliable.

Thanks.