Re: [boost] [variant] match()

Le 09/01/15 18:52, Eelis a écrit :

On 2015-01-09 10:06, Antony Polukhin wrote:

...

I like the idea of `overload` more than the `match` idea.

I see many people prefer going through apply_visitor() with overload(). Coming from a functional programming perspective, this is kinda backwards.

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

However, somewhere along the line it was decided that variant<> was to be accessed /by type/ (either through get<T>() or apply_visitor()), which means that variant does not work well at all.

Using tagged types you can always have variant, tagged> or variant.

This means variant<> fails to be the building block that sum types can/should be, because you cannot use a variant in a generic context the way you use, say, Either, in Haskell, because while Either A B works just fine when A and B might end up being the same type (because you can still distinguish the Left and Right constructors just fine), variant with its type-based access breaks down when A and B end up being the same type. either ~~ variant.

Haskel dont allow to define a sum type with the same type data X a b = a | b is invalid. The reason is that you can not distinguish one of the other. You need to use type constructors as Left or Right on the case of Either data Either a b = Left a | Right b

Really, variant<> should have been index-based all along, so that you can just do get<0> and get<1> on a variant (or a variant where A might be B) without losing information.

Well, it is not that I'm against the design, but A | A seems to me that is equal to A ;-)

Analogously, match(v, [](T){}, [](T){}) on such a variant would Just Work (again, without losing information), while apply_visitor() with overload() breaks down.

There might be legit uses for a type-indexed variant, but really, proper sums should have been the #1 priority, and it's a damn shame that variant<> didn't get it right.

I would add that there might be legit uses for nu-indexed variants, but really, proper sums are better ;-) Best, Vicente