std.data.json formal review

[Sönke Ludwig via Digitalmars-d]

Am 17.08.2015 um 20:12 schrieb Andrei Alexandrescu:
> On 8/14/15 7:40 AM, Andrei Alexandrescu wrote:
>>
>> struct TaggedAlgebraic(U) if (is(U == union)) { ... }
>>
>> Interesting. I think it would be best to rename it to TaggedUnion
>> (instantly recognizable; also TaggedAlgebraic is an oxymoron as there's
>> no untagged algebraic type). A good place for it is straight in
>> std.variant.
>>
>> What are the relative advantages of using an integral over a pointer to
>> function? In other words, what's a side by side comparison of
>> TaggedAlgebraic!U and Algebraic!(types inside U)?
>>
>> Thanks,
>>
>> Andrei
>
> Ping on this. My working hypothesis:
>
> - If there's a way to make a tag smaller than one word, e.g. by using
> various packing tricks, then the integral tag has an advantage over the
> pointer tag.
>
> - If there's some ordering among types (e.g. all types below 16 have
> some property etc), then the integral tag again has an advantage over
> the pointer tag.
>
> - Other than that the pointer tag is superior to the integral tag at
> everything. Where it really wins is there is one unique tag for each
> type, present or future, so the universe of types representable is the
> total set. The pointer may be used for dispatching but also as a simple
> integral tag, so the pointer tag is a superset of the integral tag.
>
> I've noticed many people are surprised by std.variant's use of a pointer
> instead of an integral for tagging. I'd like to either figure whether
> there's an advantage to integral tags, or if not settle for good a
> misconception.
>
>
> Andrei

(reposting to NG, accidentally replied by e-mail)

Some more points come to mind:

- The enum is useful to be able to identify the types outside of the D 
code itself. For example when serializing the data to disk, or when 
communicating with C code.

- It enables the use of pattern matching (final switch), which is often 
very convenient, faster, and safer than an if-else cascade.

- A hypothesis is that it is faster, because there is no function call 
indirection involved.

- It naturally enables fully statically typed operator forwarding as far 
as possible (have a look at the examples of the current version). A 
pointer based version could do this, too, but only by jumping through hoops.

- The same type can be used multiple times with a different enum name. 
This can alternatively be solved using a Typedef!T, but I had several 
occasions where that proved useful.

They both have their place, but IMO where the pointer approach really 
shines is for unbounded Variant types.