std.jgrandson

[Andrei Alexandrescu via Digitalmars-d]

On 8/3/14, 11:03 AM, Sönke Ludwig wrote:
> Am 03.08.2014 17:14, schrieb Andrei Alexandrescu:
[snip]
> Ah okay, *phew* ;) But in that case I'd actually think about leaving off
> the backslash decoding in the low level parser, so that slices could be
> used for immutable inputs in all cases - maybe with a name of
> "rawString" for the stored data and an additional "string" property that
> decodes on the fly. This may come in handy when the first comparative
> benchmarks together with rapidjson and the like are done.

Yah, that's awesome.

>> There's a public opCast(Payload) that gives the end user access to the
>> Payload inside a Value. I forgot to add documentation to it.
>
> I see. Suppose that opDispatch would be dropped, would anything speak
> against "alias this"ing _payload to avoid the need for the manually
> defined operators?

Correct. In fact the conversion was there but I removed it for the sake 
of opDispatch.

>> What advantages are to a tagged union? (FWIW: to me Algebraic and
>> Variant are also tagged unions, just that the tags are not 0, 1, ..., n.
>> That can be easily fixed for Algebraic by defining operations to access
>> the index of the currently-stored type.)
>
> The two major points are probably that it's possible to use "final
> switch" on the type tag if it's an enum,

So I just tried this: http://dpaste.dzfl.pl/eeadac68fac0. Sadly, the 
cast doesn't take. Without the cast the enum does compile, but not the 
switch. I submitted https://issues.dlang.org/show_bug.cgi?id=13247.

> and the type id can be easily stored in both integer and string form
> (which is not as conveniently possible with a TypeInfo).

I think here pointers to functions "win" because getting a string (or 
anything else for that matter) is an indirect call away.

std.variant has been among the first artifacts I wrote for D. It's a 
topic I've been dabbling in for a long time in a C++ context 
(http://goo.gl/zqUwFx), with always almost-satisfactory results. I told 
myself if I get to implement things in D properly, then this language 
has good potential. Replacing the integral tag I'd always used with a 
pointer to function is, I think, net progress. Things turned out fine, 
save for the switch matter.

> An enum based tagged union design also currently has the unfortunate
> property that the order of enum values and that of the accepted types
> must be defined consistently, or bad things will happen. Supporting UDAs
> on enum values would be a possible direction to fix this:
>
>      enum JsonType {
>          @variantType!string string,
>          @variantType!(JsonValue[]) array,
>          @variantType!(JsonValue[string]) object
>      }
>      alias JsonValue = TaggedUnion!JsonType;
>
> But then there are obviously still issues with cyclic type references.
> So, anyway, this is something that still requires some thought. It could
> also be designed in a way that is backwards compatible with a pure
> "Algebraic", so it shouldn't be a blocker for the current design.

I think something can be designed along these lines if necessary.


Andrei