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

Subject: Re: [boost] [variant] Please vote for behavior
From: Paul Smith (pl.smith.mail_at_[hidden])
Date: 2013-01-31 11:06:14

On Thu, Jan 31, 2013 at 9:24 AM, Antony Polukhin <antoshkka_at_[hidden]> wrote:
> From theoretical point of view you are absolutely correct, and my
> example is lame. Moreover, current implementation of move assignment
> and move constructors for recursive_wrapper were implemented to model
> that behavior.

Just pointing out that move assignment is not affected by this
discussion. Everything is already allocated so it's as efficient as a
pointer swap.

>
> But I do understand Joel's efforts to make it faster.
>
> [snip]
>
> Allowing destructive move constructor for recursive_wrapper will make
> variant at least 3 times faster.

Oh, I never said otherwise, and I definitely sympathize with the
desire to make it faster :-) What I'm saying is that this sort of
tradeoff was taken into account when move-semantics were designed, and
it's awkward to retroactively go against that.

> Leaving recursive_wrapper as is will provoke users to use a really
> slow implementation.

Well, it's not like the introduction of move semantics made existing
code slower all of the sudden :-)

> Unique_ptr and other types can not be used as a
> drop in replacement for recursive_wrapper.

That's right, although since they have different semantics, it's not
necessarily a bad thing.

>
> May be we shall deprecate recursive_wrapper and add
> recursive_ptr/nullable_recursive_wrapper class, that implements
> destructive move constructor? It does not break recursive_wrapper
> invariants,but adds a class with different invariants.

I don't think we should deprecate anything. But adding a type with
different semantics (in addition to option III which is always a good
idea) is definitely far better than changing recursive_wrapper. Let
each user pick their own poison.

--
Paul Smith