Boost logo

Boost :

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 ;-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at