On Tue, Jan 29, 2013 at 1:34 PM, Markus Klein <markus-klein@live.de> wrote:
On Fri, Jan 25, 2013 at 10:21 AM, Dave Abrahams <dave@boostpro.com> 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