What's wrong with std.variant.Variant?

[Andrei Alexandrescu]

On 6/13/20 3:42 PM, Johannes Pfau wrote:
> Am Sat, 13 Jun 2020 15:10:04 -0400 schrieb Andrei Alexandrescu:
> 
> 
>> So what's wrong with Variant? One thing I collected from a coworker is
>> that it doesn't work with Windows DLLs, because in turn typeof()
>> comparison does not work across Windows DLLs.
> 
> I think you mean typeid? This is not Variant's fault though, we really
> need full DLL support in general...

Yes, typeid, thanks.

>> What are other problems with it?
> 
> I never had any real problems with std.variant, but I have some smaller
> nits:
> 
> * Does the Algebraic implementation use typeid/TypeInfo? I think that's
> not documented and I'd prefer a numeric/enum tag

I think so. It was just for the sake of reusing the same codebase for 
Algebraic and Variant.

An enum might save space in some instances, but in most cases it simply 
eats a word anyway. But, space is important so this should go on the 
list. E.g. there should be no reason Algebraic!(char, byte, ubyte) 
should eat more than 2 bytes.

> * Memory Management is not documented

Yah, that whole thing with dynamic allocation and eager copying of types 
greater than a threshold.

> Algebraic has to compete with https://code.dlang.org/packages/
> taggedalgebraic which has some more features. I never really liked the
> Agelbraic APIs (phobos and TaggedAlgebraic: casting to get values /
> explicit get calls etc.). I prefer something with a union-like interface
> like TaggedUnion:
> 
> union Base
> {
>      int a;
>      string b;
> }
> 
> alias Type = TaggedUnion!Base;
> 
> Type t = Type(0);
> t.a = 42;
> t.b = "foo";
> writeln(t.b);
> if (t.kind == Type.Kind.Foo)
> if (t.isFoo)...

Interesting, so members should receive names much like they do in 
std.tuple. Cool. I think this could be done.


Andrei