RFC: std.json sucessor

[Don via Digitalmars-d]

On Wednesday, 27 August 2014 at 23:51:54 UTC, Walter Bright wrote:
> On 8/26/2014 12:24 AM, Don wrote:
>> On Monday, 25 August 2014 at 23:29:21 UTC, Walter Bright wrote:
>>> On 8/25/2014 4:15 PM, "Ola Fosheim Grøstad"
>>> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
>>>> On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright 
>>>> wrote:
>>>>> I didn't know that. But recall I did implement it in DMC++, 
>>>>> and it turned out
>>>>> to simply not be useful. I'd be surprised if the new C++ 
>>>>> support for it does
>>>>> anything worthwhile.
>>>>
>>>> Well, one should initialize with signaling NaN. Then you get 
>>>> an exception if you
>>>> try to compute using uninitialized values.
>>>
>>>
>>> That's the theory. The practice doesn't work out so well.
>>
>> To be more concrete:
>>
>> Processors from AMD have signalling NaN behaviour which is 
>> different from
>> processors from Intel.
>>
>> And the situation is worst on most other architectures. It's a 
>> lost cause, I think.
>
> The other issues were just when the snan => qnan conversion 
> took place. This is quite unclear given the extensive constant 
> folding, CTFE, etc., that D does.
>
> It was also affected by how dmd generates code. Some code gen 
> on floating point doesn't need the FPU, such as toggling the 
> sign bit. But then what happens with snan => qnan?
>
> The whole thing is an undefined, unmanageable mess.

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.

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.

Because of this, I think SNAN only ever makes sense for static 
variables. Setting local variables to snan doesn't make sense. 
since the snan has to enter the CPU. Making that work without 
triggering the snan is very painful. Making it trigger the snan 
on all forms of access is even worse.

If float.init exists, it cannot be an snan, since you are allowed 
to use float.init.