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
