Movement against float.init being nan

[Paul Backus]

On Thursday, 25 August 2022 at 11:38:22 UTC, max haughton wrote:
> On Thursday, 25 August 2022 at 09:07:54 UTC, user1234 wrote:
>> On Thursday, 25 August 2022 at 07:15:58 UTC, bauss wrote:
>>> On Thursday, 25 August 2022 at 03:08:54 UTC, Steven 
>>> Schveighoffer wrote:
>>>>
>>>> A better option would be to throw an exception if NaN is 
>>>> used in an operation.
>>>>
>>>> -Steve
>>>
>>> IMHO this is the better solution and not even an exception, 
>>> but Error.
>>>
>>> As soon as you have any NaN values that are being used your 
>>> program is effectively useless and broken.
>>>
>>> I think as soon as any variable becomes NaN it should throw, 
>>> not just when an operation happens.
>>>
>>> Basically I think it should throw when either of these 
>>> conditions holds true:
>>>
>>> - A value was initialized as NaN and used in an operation
>>> - A value was set to NaN outside of initialization
>>> - NaN is returned from a function (Even if not set to a 
>>> variable or anything.)
>>
>> I'm shocked by this idea. What if I want high performance 
>> nothrow FP code ?
>
> Turn the check off. The hardware basically already supports 
> doing this (NaNs don't have to be quiet) but almost no one uses 
> it - it's quite hard to trigger at all on a modern system.

Looks like D allows you to enable floating-point exceptions using 
the [`std.math.hardware.FloatingPointControl`][1] interface.

Of course, these are hardware exceptions, so you will get SIGFPE 
rather than a thrown Error with a backtrace. To turn them into D 
Errors you'd need to set up a signal handler, like how 
`etc.linux.memoryerror` does it (or whatever the equivalent is on 
Windows).

[1]: 
https://phobos.dpldocs.info/std.math.hardware.FloatingPointControl.html