Re: [boost] [variant] Please vote for behavior

Subject: Re: [boost] [variant] Please vote for behavior
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-01-30 08:23:17

On 01/30/13 00:32, Jeffrey Lee Hellrung, Jr. wrote:
> On Tue, Jan 29, 2013 at 1:34 PM, Markus Klein <markus-klein_at_[hidden]> wrote:
> 
>> On Fri, Jan 25, 2013 at 10:21 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>>
>>> Yes.  IIUC the question here is whether the invariant of variant [;-)]
>>> shall be weakened to accommodate efficient move semantics, thereby
>>> breaking some code, or not, at some cost (the specific costs to be
>>> incurred by various strategies presently under discussion).
>>
>> I'm new to this list, so I won't be offended if you correct me on any
>> rookie
>> mistakes.
>> Concerning the invariant of variant:
>> Why not provide a specialization of boost::optional for variant, which
>> supports move
>> Semantics? Users who don't want their invariant harmed, can use
>> boost::variant as is.
>> Users who need to squeeze out performance could use an optional<variant>
>> and
>> would
>> be explicitly aware of the new null state they introduced for this.
>>
> 
> Why I don't think that's a particularly good idea:
> - optional< variant<blah> > doesn't have the same interface as
> variant<blah>.
> - It's a lot of syntactic noise.
> - It isn't obvious that you're using optional< variant<blah> > primarily to
> enable move semantics.
> - We can still get proper move semantics for variant in most use cases
> without ever violating the never-empty guarantee. This is only ever an
> issue for a recursive variant which is not default-constructible. The fix
> is easy: prepend your typelist with boost::blank.
> 
Hmm... Just brainstorming here:
What about deriving the current variant from a new class,
variant_core, which didn't have all the TMP used by the current
variant for handling recursion( for example, look at all the
TMP described here:
http://www.boost.org/doc/libs/1_52_0/doc/html/boost/make_recursive_variant.html
).

Also, variant_core might not even need to have a never-empty
guarantee if variant_core.which() is allowed to return some
value indicating empty.

IOW, variant_core would have *less* constraints than
variant which seems consistent with the idea that
a base class has *less* constraints than the derived
class (where constraint here means either more member
variables or functions or more specific virtual
functions).

Thoughts?

-regards,
Larry