A Philosophy of Software Design

[Forum User]

On Sunday, 28 June 2026 at 02:15:37 UTC, Walter Bright wrote:
> On 6/27/2026 5:13 PM, Forum User wrote:
>> On Saturday, 27 June 2026 at 19:48:44 UTC, Walter Bright wrote:
>>> [...]
>>> It behaves much like the floating point NaN value, which is a 
>>> generally misunderstood and underappreciated.
>> 
>> NaNs increase hidden complexity and require more source code
>> (i.e. increase source code complexity) in order to do things 
>> right:
>> 
>>     auto t = (t2);
>>     if (t < 2.0)
>>        writeln ("met the climate target");
>>     else
>>        writeln ("failed to meet the climate target");
>
> The reader would want to know how well the number met the 
> target, or how badly it failed:

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.

> [...]
> Besides, getting a NaN result is always better than getting an 
> arbitrary number with no clue whether it is valid or a bug.

There is no number printed in the invalid case in any of the
snippets presented so far.