Re: [boost] [variant] match()

Subject: Re: [boost] [variant] match()
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-09 13:34:10

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<T, T> does not work well at all.
>
Using tagged types you can always have variant<tagged<T, left>, 
tagged<T, right>> or variant<left<T>, right<T>>.
> This means variant<> fails to be the building block that sum types 
> can/should be, because you cannot use a variant<A, B> 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<A, B> with its type-based access breaks down when 
> A and B end up being the same type.
either<A,B> ~~ variant<left<A>, right<B>>.

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<T, T> (or a variant<A, B> 
> 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