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