on Wed Jan 30 2013, Joel de Guzman <djowel-AT-gmail.com> wrote:
On 1/30/13 1:25 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Jan 29, 2013 at 7:12 AM, Paul Smith <pl.smith.mail@gmail.com> wrote:
This discussion might be facilitated if Joel et al (sorry Joel, I don't mean to pick on you, I just mean the group arguing for introducing this "singular" post-move state) simply said "yes, we understand we're making a breaking change (by possibly introducing an additional state to variant that violates the never-empty guarantee), but we still think it's the most practical approach to introduce efficient move semantics to variant". I can jive with that but I think Paul's concerned that you (again, as a representative of the platform you're taking) don't appreciate that this is a breaking change to variant.
No, Jeff, that is wrong. We are not violating the semantics to variant. It's not about variant. It's about recursive_wrapper. I think people are confused with this. The variant's never-empty guarantee still holds. A variant holding a singular-valued recursive_wrapper is similar to a variant holding a singular valued iterator. The variant is not empty.
But Joel, IIUC a variant never actually, from the abstract interface point-of-view, contains a recursive_wrapper anyway. Isn't the recursive_wrapper just a detail required to make it possible for a variant type to (logically) contain itself? A visitor never sees the recursive_wrapper, for example, and the never-empty guarantee doesn't says that the variant always contains one of the types it can logically contain. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost