"Eric Friedman" <[EMAIL PROTECTED]> writes: > While this is certainly quite implementable, I feel a bit uneasy about > hinging variant's exception-safety guarantees on such a small point as > whether 'void' content is allowed. I imagine it would not only make variant > more confusing to use but also may not satisfactorily solve the problem of > delegating the space-vs-safety decision to the user. > > I'm interested in feedback on this issue.
Here's the way I see the issue: 1. Being able to maintain a sensible invariant for variant<> (ugh, English can rot sometimes) is important. b. "One or none" (i.e. maybe-empty) is a reasonable-sounding invariant. Given that one has to ask what kind of contents are in the variant in order to do anything with them**, it's hard for me to imagine a case where "one or none" would be any worse than "exactly one". c. However, if someone can show code or program logic that is complicated by "one or none", I'm perfectly willing to accept that "exactly one" is a more-reasonable invariant for some or most applications. Iff it's "most", including void as one of the variant types to achieve "one or none" functionality sounds quite elegant. 2. Having a strong-guarantee assignment is NOT important, and in particular should never be bought at the cost of (space or time) efficiency. You can see my writings on why copy/swap is a poor choice for "canonical assignment" for rationale. In this case, the strong guarantee falls out of the implementation technique required to achieve "exactly one", and is not a goal in and of itself. In that case, I see no problem at all that you only get the basic guarantee in the "one or none" case. -Dave ** or get an exception trying to retrieve them, of course -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost