Re: [boost] variant - off topic

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;