formal review

Sönke Ludwig via Digitalmars-d digitalmars-d at
Tue Aug 4 06:10:09 PDT 2015

Am 03.08.2015 um 23:15 schrieb deadalnix:
> On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
>> Start of the two week process, folks.
>> Code:
>> Docs:
>> Atila
> Looked in the doc (
> ). I wanted to know how JSONValue can be manipulated. That is not very
> explicit.
> First, it doesn't looks like the value can embed null as a value. null
> is a valid json value.

The documentation is lacking, I'll improve that. JSONValue includes an 
alias this to an Algebraic, which provides the actual data API. Its type 
list includes typeof(null).

> Secondly, it seems that it accept bigint. As per JSON spec, the only
> kind of numeric value you can have in there is a num, which doesn't even
> make the difference between floating point and integer (!) and with 53
> bits of precision. By having double and long in there, we are already
> way over spec, so I'm not sure why we'd want to put bigint in there.

See also my reply a few posts back. JSON does not specify anything WRT 
the precision or length of numbers. In the ECMA standard it is mentioned 
explicitly that this was done so that applications are not limited in 
what kind of numbers can be transferred. The only thing explicitly 
mentioned is that implementations *may* choose to support only 64-bit 
floats. But large integer numbers are used in practice, so we should be 
able to handle those, too (one way or another).

> Finally, I'd love to see that JSONValue to exhibit a similar API than
> jsvar.

This is how it used to be in the module. I consider that 
to be a mistake now for multiple reasons, at least on this abstraction 
level. My proposal would be to have a clean, "strongly typed" JSONValue 
and a generic jsvar like struct on top of that, which is defined 
independently, and could for example work on a BSONValue, too. The usage 
would simply be "var value = parseJSONValue(...);".

More information about the Digitalmars-d mailing list