std.data.json formal review

[Sönke Ludwig via Digitalmars-d]

Am 18.08.2015 um 00:37 schrieb Andrei Alexandrescu:
> On 8/17/15 2:56 PM, Sönke Ludwig wrote:
>> - 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.
>
> OK.
>
>> - It enables the use of pattern matching (final switch), which is often
>> very convenient, faster, and safer than an if-else cascade.
>
> Sounds tenuous.

It's more convenient/readable in cases where a complex type is used 
(typeID == Type.object vs. has!(JSONValue[string]). This is especially 
true if the type is ever changed (or parametric) and all has!()/get!() 
code needs to be adjusted accordingly.

It's faster, even if there is no indirect call involved in the pointer 
case, because the compiler can emit efficient jump tables instead of 
generating a series of conditional jumps (if-else-cascade).

It's safer because of the possibility to use final switch in addition to 
a normal switch.

I wouldn't call that tenuous.

>
>> - A hypothesis is that it is faster, because there is no function call
>> indirection involved.
>
> Again: pointers do all integrals do. To compare:
>
> if (myptr == ThePtrOf!int) { ... this is an int ... }
>
> I want to make clear that this is understood.

Got that.

>
>> - 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.
>
> I'm unclear on that. Could you please point me to the actual file and
> lines?

See the operator implementation code [1] that is completely statically 
typed until the final "switch" happens [2]. You can of course do the 
same for the pointer based Algebraic, but that would just 
duplicate/override the code that is already implemented by the pointer 
method.

>> - 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.
>
> Unclear on this.

I'd say this is just a little perk of the representation but not a hard 
argument since it can be achieved in a different way relatively easily.

[1]: 
https://github.com/s-ludwig/taggedalgebraic/blob/591b45ca8f99dbab1da966192c67f45354c1e34e/source/taggedalgebraic.d#L145
[2]: 
https://github.com/s-ludwig/taggedalgebraic/blob/591b45ca8f99dbab1da966192c67f45354c1e34e/source/taggedalgebraic.d#L551