Am Sun, 03 Aug 2014 08:34:20 -0700 schrieb Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
> On 8/3/14, 2:38 AM, Sönke Ludwig wrote: > [snip] > > We need to address the matter of std.jgrandson competing with > vibe.data.json. Clearly at a point only one proposal will have to be > accepted so the other would be wasted work. > > [...] > > 4. Avoid string allocation. String allocation can be replaced with > slices of the input when these two conditions are true: (a) input > type is string, immutable(byte)[], or immutable(ubyte)[]; (b) there > are no backslash-encoded sequences in the string, i.e. the input > string and the actual string are the same. I think for the lowest level interface we could avoid allocation completely: The tokenizer could always return slices to the raw string, even if a string contains backslash-encode sequences or if the token is a number. Simply expose that as token.rawValue. Then add a function, Token.decodeString() and token.decodeNumber() to actually decode the numbers. decodeString could additionally support decoding into a buffer. If the input is not sliceable, read the input into an internal buffer first and slice that buffer. The main usecase for this is if you simply stream lots of data and you only want to parse very little of it and skip over most content. Then you don't need to decode the strings. This is also true if you only write a JSON formatter: No need to decode and encode the strings. > > 5. Build on std.variant through and through. Again, anything that > doesn't work is a usability bug in std.variant, which was designed > for exactly this kind of stuff. Exposing the representation such that > user code benefits of the Algebraic's primitives may be desirable. > Variant uses TypeInfo internally, right? I think as long as it uses TypeInfo it can't replace all use-cases for a standard tagged union.
