"Jacob Carlborg"  wrote in message news:lrqvfa$2has$1@digitalmars.com...

> I'm not saying that is a bad idea or that I don't want to be able to do this. I just prefer this to be handled by a generic serialization module. Which can of course handle the simple cases, like above, as well.

I know, but I don't really care if it's part of a generic serialization library or not.  I just want it there.  Chances are tying it to a future generic serialization library is going to make it take longer. 

On 8/5/14, 8:23 AM, Daniel Murphy wrote:
> "Andrea Fontana"  wrote in message
> news:takluoqmlmmooxlovqya@forum.dlang.org...
>
>> If I'm right, json has just one numeric type. No difference between
>> integers / float and no limits.
>>
>> So probably the mapping is:
>>
>> float/double/real/int/long => number
>
> Maybe, but std.json has three numeric types.

I searched around a bit and it seems different libraries have different takes to this numeric matter. A simple reading of the spec suggests that floating point data is the only numeric type. However, many implementations choose to distinguish between floating point and integrals.

Andrei

On Tuesday, 5 August 2014 at 17:17:56 UTC, Andrei Alexandrescu wrote:
> On 8/5/14, 8:23 AM, Daniel Murphy wrote:
>> "Andrea Fontana"  wrote in message
>> news:takluoqmlmmooxlovqya@forum.dlang.org...
>>
>>> If I'm right, json has just one numeric type. No difference between
>>> integers / float and no limits.
>>>
>>> So probably the mapping is:
>>>
>>> float/double/real/int/long => number
>>
>> Maybe, but std.json has three numeric types.
>
> I searched around a bit and it seems different libraries have different takes to this numeric matter. A simple reading of the spec suggests that floating point data is the only numeric type. However, many implementations choose to distinguish between floating point and integrals.

There is certain benefit in using same primitive types for JSON as ones defined by BSON spec.

On Tuesday, 5 August 2014 at 17:17:56 UTC, Andrei Alexandrescu
wrote:
>
> I searched around a bit and it seems different libraries have different takes to this numeric matter. A simple reading of the spec suggests that floating point data is the only numeric type. However, many implementations choose to distinguish between floating point and integrals.

The original point of JSON was that it auto-converts to
Javascript data.  And since Javascript only has one numeric type,
of course JSON does too.  But I think it's important that a JSON
package for a language maps naturally to the types available in
that language.  D provides both floating point and integer types,
each with their own costs and benefits, and so the JSON package
should as well.  It ends up being a lot easier to deal with than
remembering to round from JSON.number or whatever when assigning
to an int.

In fact, JSON doesn't even impose any precision restrictions on
its numeric type, so one could argue that we should be using
BigInt and BigFloat.  But this would stink most of the time, so...

On an unrelated note, while the default encoding for strings is
UTF-8, the RFC absolutely allows for UTF-16 surrogate pairs, and
this must be supported.  Any strings you get from Internet
Explorer will be encoded as UTF-16 surrogate pairs regardless of
content, presumably since Windows uses 16 bit wide chars for
unicode.

On 8/5/14, 10:48 AM, Sean Kelly wrote:
> On Tuesday, 5 August 2014 at 17:17:56 UTC, Andrei Alexandrescu
> wrote:
>>
>> I searched around a bit and it seems different libraries have
>> different takes to this numeric matter. A simple reading of the spec
>> suggests that floating point data is the only numeric type. However,
>> many implementations choose to distinguish between floating point and
>> integrals.
>
> The original point of JSON was that it auto-converts to
> Javascript data.  And since Javascript only has one numeric type,
> of course JSON does too.  But I think it's important that a JSON
> package for a language maps naturally to the types available in
> that language.  D provides both floating point and integer types,
> each with their own costs and benefits, and so the JSON package
> should as well.  It ends up being a lot easier to deal with than
> remembering to round from JSON.number or whatever when assigning
> to an int.
>
> In fact, JSON doesn't even impose any precision restrictions on
> its numeric type, so one could argue that we should be using
> BigInt and BigFloat.  But this would stink most of the time, so...
>
> On an unrelated note, while the default encoding for strings is
> UTF-8, the RFC absolutely allows for UTF-16 surrogate pairs, and
> this must be supported.  Any strings you get from Internet
> Explorer will be encoded as UTF-16 surrogate pairs regardless of
> content, presumably since Windows uses 16 bit wide chars for
> unicode.

All good points. Proceed with implementation! :o) -- Andrei

On Tuesday, 5 August 2014 at 17:58:08 UTC, Andrei Alexandrescu wrote:
> All good points. Proceed with implementation! :o) -- Andrei

Any news about std.allocator ? ;)

On Tue, Aug 05, 2014 at 10:58:08AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 8/5/14, 10:48 AM, Sean Kelly wrote:
[...]
> >The original point of JSON was that it auto-converts to Javascript data.  And since Javascript only has one numeric type, of course JSON does too.  But I think it's important that a JSON package for a language maps naturally to the types available in that language.  D provides both floating point and integer types, each with their own costs and benefits, and so the JSON package should as well.  It ends up being a lot easier to deal with than remembering to round from JSON.number or whatever when assigning to an int.
> >
> >In fact, JSON doesn't even impose any precision restrictions on its numeric type, so one could argue that we should be using BigInt and BigFloat.  But this would stink most of the time, so...

Would it make sense to wrap a JSON number in an opaque type that implicitly casts to the target built-in type?


> >On an unrelated note, while the default encoding for strings is UTF-8, the RFC absolutely allows for UTF-16 surrogate pairs, and this must be supported.  Any strings you get from Internet Explorer will be encoded as UTF-16 surrogate pairs regardless of content, presumably since Windows uses 16 bit wide chars for unicode.
[...]

Wait, I thought surrogate pairs only apply to characters past U+FFFF? Is it even possible to encode BMP characters with surrogate pairs?? Or do you mean UTF-16?


T

-- 
Music critic: "That's an imitation fugue!"

On 8/5/14, 10:58 AM, Dicebot wrote:
> On Tuesday, 5 August 2014 at 17:58:08 UTC, Andrei Alexandrescu wrote:
>> All good points. Proceed with implementation! :o) -- Andrei
>
> Any news about std.allocator ? ;)

It looks like I need to go all out and write a garbage collector, design and implementation and all.

Andrei

On Tuesday, 5 August 2014 at 18:12:54 UTC, Andrei Alexandrescu wrote:
> On 8/5/14, 10:58 AM, Dicebot wrote:
>> On Tuesday, 5 August 2014 at 17:58:08 UTC, Andrei Alexandrescu wrote:
>>> All good points. Proceed with implementation! :o) -- Andrei
>>
>> Any news about std.allocator ? ;)
>
> It looks like I need to go all out and write a garbage collector, design and implementation and all.

A few months ago, you posted a video of a talk where you presented code from a garbage collector (it used templated mark functions to get precise tracing). I remember you said that this code was in use somewhere (I guess at FB?). Can this be used as a basis?

On 2014-08-05 18:42, Daniel Murphy wrote:

> Chances are tying it to a future
> generic serialization library is going to make it take longer.

Yeah, that's the problem. But where do you draw the line. Should arrays of structs be supported?

-- 
/Jacob Carlborg