std.jgrandson

[Andrei Alexandrescu via Digitalmars-d]

On 8/3/14, 8:51 AM, Johannes Pfau wrote:
> Am Sun, 03 Aug 2014 08:34:20 -0700
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail at 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.

That works but not e.g. for File.byLine which reuses its internal 
buffer. But it's a neat idea for arrays of immutable bytes.

> If the input is not sliceable, read the input into an internal buffer
> first and slice that buffer.

At that point the cost of decoding becomes negligible.

> 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.

Awesome.

> This is also true if you only
> write a JSON formatter: No need to decode and encode the strings.

But wouldn't that still need to encode \n, \r, \t, \v?

>> 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?

No.


Andrei