Re: [boost] [variant] Heads-up!
There seems to be misunderstanding of what the thread is about. The short sum-up of the changes: Nothing changed for users that does not use recursive variant. The changes were applied mainly for recursive_wrapper, and affect recursive variant indirectly. The PR was proposed as a solution for two major recursive variant problems: * Move-only types support * Poor move performance (because of this one Spirit has its own variant) Most of the users are not affected by recursive_wrapper move constructor change. To hit it you have to visit (either directly, or with applying comparison operators) a recursive moved-out variant.
have to agree with Steven. Never empty guarantee is a crucial difference between Boost.Variant and std::variant.
std::variant has no recursive variant support. In the common field nothing changed. See the comment above.
If the one negative is adding UB to valid existing code at the next point release, doesn't that outweigh any number of positive outcomes?
I do not think there even a single user that visits moved-out variants. There is an assertation for such usage though.
Why wouldn't this be an opt-in strategy - this property of moves has been established for years now.
Because it solves the bigger problems and for much more users that it potentially breaks.
On Mon, Apr 29, 2019 at 4:08 PM Nikita Kniazev via Boost
There seems to be misunderstanding of what the thread is about.
The short sum-up of the changes: Nothing changed for users that does not use recursive variant. The changes were applied mainly for recursive_wrapper, and affect recursive variant indirectly.
Would your problems also be solved if there were a separate type, different from recursive_wrapper, that is similar but explicitly has an empty state (basically just a dynamic optional implementation, as described in the other thread)? I believe this solves the performance concerns without impacting existing users. The other suggestions on how to do what you want without violating the never empty guarantee or introducing a new valid state to recursive_wrapper would also be positive regardless, imo. -- -Matt Calabrese
On Mon, Apr 29, 2019 at 4:55 PM Nikita Kniazev
Would your problems also be solved if there were a separate type, different from recursive_wrapper, that is similar but explicitly has an empty state
This can be done, but it leaves recursive_wrapper in the broken state for move only types and increases complexity of the variant.
Calling "recursive_wrapper" broken is a matter of debate, and I suspect you're in the minority for that specific argument. For many, recursive_wrapper itself is, on its own, okay. The less-controversial statement is that there is no simple way to get the semantics that you want, with the performance that you want. I suspect that the answer may be closer to either a template that is different, but similar to recursive_wrapper, or alternatively, a template that is similar but different from a never-empty variant. -- -Matt Calabrese
participants (2)
-
Matt Calabrese -
Nikita Kniazev