Boost logo

Boost :

Subject: Re: [boost] variant - off topic
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-03 21:58:14


śr., 3 kwi 2019 o 23:28 Robert Ramey via Boost <boost_at_[hidden]>
napisał(a):

> I've been and observer on the discussions regarding variant, expected,
> outcome, optional, outcome and ?? for sometime. I'm pretty amazed at
> the amount of controversy each and everyone of these in every forum -
> here, C++ committee, etc. I'm beginning to wonder this isn't telling us
> something.
>
> It seems natural that when making a new C++ data type, we should want to
> implement the assignment operator. Why - well every variable needs to be
> assigned to from time to time. Why is this so? Well ...
>
> Suppose we break this assumption and consider the idea that assignment
> doesn't make sense for every type. A variant is a "meta-type" or "sum
> type" which "holds" one of a set of other types. Such a variant can take
> on the character of any one of type types it is holding. When does it
> make conceptual sense for a variable to change it's type one it has been
> initially assigned. I've been trying to think of one and haven't been
> successful. Here are a few of the scenarios I've considered.
>
> a) Returning a sum type - the most common scenario for a variant.
> Doesn't require a assignment. Copy/move may still be required of course.
>
> b) looping through a vector of variants as in
>
> vector variant<...> v;
> for( variant<...> v : [](){...}
>
> fix with change to
>
> vector variant<...> v;
> for( variant<...> & v : [](){...}
>
> c) set according to condition
>
> variant<...> r;
> if(i < 0)
> r = v<t1>(...)
> else
> r = v<t2>(...)
>
> fix with change to
>
> variant <...> r = (i < 0) ? v<t1>(...) : v<t2>(...);
>
> d) insert your own use case here. That is, look at your own usages of
> assignment to these types and see if there is not an easy way to
> re-factor your code to avoid assignment.
>
> I'll concede that, influenced by functional programming style, with a
> little experimentation with F# and propaganda from the Haskell
> community, I've become accustomed to code in the above way. Also I've
> become afraid to assign anything to these types. The discussion has
> made me aware of a raft of unintended consequences of doing what on it's
> surface seems a trivial operation. I've gotten to the point that
> assignment to a variant type, or "changing the type" of a value at
> runtime is not code smell to me. Maybe all this could be just
> eliminated if this became the accepted position.
>
> Of course I realize that by engaging in the practice I do, the whole
> issue becomes irrelevant to me personally. And I can always create
> variant types as "const". It's not about that. It's about avoiding the
> creating of vocabulary types which lead to problems.
>
> So - simple proposal. Require that sum types have operator= deleted.
>
> Robert Ramey
>

It is an interesting observation. I am not sure about the consequences,
though. It is not only assignment. I ti s also swap. STL algorithms, such
as sort() use assignment and swap inside. The question is: should std::sort
on variants work? Or because of the special properties of a variant some
STL algorithms should break, maybe storage in containers should be
prohibitted? For sure, the assignment of such containers would be banned.

Regards,
&rzej;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk