What's wrong with std.variant.Variant?

[Dukc]

On Saturday, 13 June 2020 at 19:10:04 UTC, Andrei Alexandrescu 
wrote:
> 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.
>
> What are other problems with it?

I have used both `std.variant` and DUB package Taggedalgebraic in 
a real project, so I think I can testify.

There is nothing absolutely wrong about Phobos variant -it is 
definitely an improvement over `union`s or `void[someSize]` in 
the general case. If I wanted to make a variant without 
pre-specifying the types, I'd still consider it (through I'd most 
likely check the Tardy library Atila just announced first).

But all my use cases have been ones where I can pre-provide a 
list. The typical thing I want to do is to either return a normal 
value or an error value. I personally don't like exceptions 
because I want to give the calling code an option to treat errors 
as normal low-level results without performance implications.

For that use, `std.variant` proved itself serviceable, but not 
optimal. The first problem is that it always has one separate 
`null` value. I want to be able to specify an arbitrary number of 
different null values, or to have none at all. 
`taggedalgebraic.TaggedUnion` lets me do this, with the `Void` 
type provided by the package.

The second problem is that standard variant will not work with 
any of the attributes. `TaggedUnion` neither works with `nothrow` 
or `@nogc`, but at least it has no problems with `@safe` and 
`pure`. The latter two are more important anyway.

And finally, with `TaggedUnion` the union can contain the same 
type two times, being still separate by it's tag value. If I want 
a tagged version of this:

```
union PictureSize
{   int[2] inPixels;
     float[2] inMeters;
     float[2] inSourceSizes;
}
```

...I can't do that with the standard variant.