On 8/21/18 3:11 PM, Nick Sabalausky (Abscissa) wrote:
On 08/21/2018 03:03 AM, Nicholas Wilson wrote:
On Monday, 20 August 2018 at 00:27:04 UTC, Nick Sabalausky (Abscissa)
wrote:
Suppose I've wrapped a Variant in a struct/class which ensures the
Variant *only* ever contains types which satisfy a particular
constraint (for example: isInputRange, or hasLength, etc...).
Is there a way to call a function (ex: popFront) on the Variant,
*without* knowing ahead of time all the possible static types it
might might contain?
I assume you mean at compile time AoT of development of your library?
Yes, don't use Variant; use https://github.com/s-ludwig/taggedalgebraic
TaggedAlgebraic requires a finite list of every type it can contain.
That's the deal-breaker for what I had in mind. I need something less
like Algebraic and more like Variant, which *doesn't* require a finite,
canonical list of every type it can contain.
The more I think about it though, the more I'm not so sure that the
extensibility is important enough to warrant all of this, or...more
importantly...that all of this is even necessary anyway for users to
accomplish the use-cases I had in mind. I think I may go with an
entirely different approach.
If you examine how the code for variant works, it's quite clever. It
establishes a "handler" that is generated with full compile-time type
info available when the value is *assigned*, but then cast to a function
taking a void pointer and an operation. This way, the user of the
variant doesn't have to know what is inside, just the handler does. The
code that sets the payload is the one that establishes how to use it.
The same type of pattern could be used to, for instance, provide all the
functions that a range uses.
But it's not something that can be tacked on to Variant. You'd have to
write your own type, because you'd have to handle the different
functions that you know are common between the types in question (e.g.
the operations supported on a variant are here:
https://github.com/dlang/phobos/blob/master/std/variant.d#L163)
-Steve
