A Philosophy of Software Design

[Kapendev]

On Sunday, 28 June 2026 at 07:35:45 UTC, Forum User wrote:
> Actually the NaN-aware code must read like this:
>
> ```d
> if (t != t) {
>     writeln ("a NaN occured");
>     // stop execution, return error code
> }
> else if (t < 2.0)
>     writeln ("%g met the climate target", t);
> else
>     writeln ("%g failed to meet the climate target", t);
> ```
>
> I neither want to write nor read such code.
>
> But the usual case is that the (contaminated) value is not 
> intended
> to be presented to the reader of the program output. Every 
> internal
> double variable is subject to such contamination. Lots of 
> numerical
> algorithms contain branches based on then invalid comparisions 
> and
> there is no NaN-propagation across such branches. The result 
> is: The
> formerly detected error is swept under the carpet.
>
> THIS is a totally underappreciated source of errors.

You can misuse any feature, even good ones like NaN.
It's a number type. You usually want to continue executing 
instead of crashing when doing math. "Garbage data" in this 
specific case is good and an OK way to handle errors. If it was 
another kind of type, then maybe it makes sense to have a 
different way to handle errors.

-- *A diverse mix of error types is very good for your health.* 
-- *Diogenes of Sinope*