std.jgrandson

[H. S. Teoh via Digitalmars-d]

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!"