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

Subject: Re: [boost] [variant] Please vote for behavior
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-01-30 01:32:32

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.

Also, welcome to the list, and don't let the above shy you away from
sharing ideas :) I just don't think specializing optional< variant<blah> >
is better than the other alternatives.

- Jeff