RFC: std.json sucessor

[via Digitalmars-d]

On Thursday, 28 August 2014 at 11:09:16 UTC, Don wrote:
> I think the way to think of it is, to the programmer, there is 
> *no such thing* as an snan value. It's an implementation detail 
> that should be invisible.
> Semantically, a signalling nan is a qnan value with a hardware 
> breakpoint on it.

I disagree with this view.

QNAN: there is a value, but it does not result in a real

SNAN: the value is missing for an unspecified reason

AFAIK some x86 ops such as ROUNDPD allows you to treat SNAN as 
QNAN or throw an exception. So there is an builtin test if needed.

Other ops such as reciprocals don't throw any FP exceptions and 
will treat SNAN as QNAN.

> An SNAN should never enter the CPU. The CPU always converts 
> them to QNAN if you try. You're kind of not supposed to know 
> that SNAN exists.

I'm not sure how you reached this interpretation?

The solution should be to emit a test for SNAN explicitly or 
implicitly if you cannot prove that SNAN is impossible.