Re: [boost] [variant] match()

On 01/09/2015 12:35 PM, Matt Calabrese wrote:

On Fri, Jan 9, 2015 at 9:52 AM, Eelis wrote:

[snip]

...

What we need is sum types. C++ unions are sort of sum types, but they're crap, so variant<> is our C++ workaround.

[snip]

That's not why a variant has no repeated types.

I thought it didn't allow repeated types because accessing by the type would then be ambiguous. IOW, for variant, which element would get<T>(variant*) get, the 1st or 2nd? [snip]

...

This means variant<> fails to be the building block that sum types can/should be

Not true. It is trivial to build a generalized discriminated union on top of variant. All you do is have the discriminated_union template contain a variant, wrapper, wrapper...>.

Sure, but then all the template progamming designed to get the discriminant based on type becomes redundant.

It is also trivial to go the other way around -- build a variant on top of discriminated_union.

Which seems simpler to me. After all, implementing the discriminated union involves, at first, just the "primitives": 1) calculating the size an alignment of a buffer 2) using the tag to find the right type in a type list as in the mpl::at_c<tag>: http://www.boost.org/doc/libs/1_31_0/libs/mpl/doc/ref/Reference/at_c.html Using variant, step 1 is the same, but how is step 2 implemented? It seems it would involve a metaprogram to search through the bounded types to find a match. Isn't that more complicated and compile-time intensive? Why not 1st do the simpler discriminated union, and then, if someone wants the type variant, implement that on top of the discriminated union?

That said, in practice, I've personally found it best to build them both from scratch on top of lower-level primitives

Could you describe the lower-level primitives? [snip] -regards, Larry