Christopher Wright wrote:
Your Variant can be extended more easily than mine. Your Variant is
faster than mine. But yours cannot be used everywhere, and mine can.
But this may be an artificial constraint. For example, you may say "my
variant can be used with old-style variadics". Phobos' doesn't, but I
don't think that's important.
Here's where I think std.variant is limited:
1. In interfacing with equally general variants implemented
independently. I know it sounds a bit cryptic, but I couldn't find a
simpler way to put it.
2. In storing structs larger than a threshold. I know how to do that and
there's a bugzilla on it, just haven't gotten around to implementing it.
Other than that it compares very favorably with other implementations
I've written and read. In particular it has the same "bigger fish"
design that std.algorithm has: it includes alternative designs as
particular cases.
Also, given that only a very few operations can ever be supported by
Variant, I think it's not a big deal if Variant never lets you do
anything interesting with the stored values besides boxing, unboxing,
equality testing, hashing, and any standard reflection stuff that is
available.
Not quite getting that. (Extensibility wasn't an essential concern for
Phobos' Variant.) So yes, there are some primitives that variants should
support. The point is making those primitives fast, otherwise
dynamic-typed programming in D wouldn't be compelling.
That being said, I never ran speed comparisons, so I expect I'll be
thoroughly surprised.
Andrei
