On Tue, Dec 9, 2014 at 1:31 PM, Peter Dimov <lists@pdimov.com> wrote:
Matt Calabrese wrote:
While that's true, the old behavior seems about as compelling to me as if the language allowed you to static_cast between any two types, but yielded a null pointer at run-time if there were no valid conversion.
That's not true. Both get variants can fail (at runtime) if the variant doesn't contain the target, so your code that uses either MUST be prepared to deal with this case. The difference is only that one of them allows you to ask "does this variant<X,Y> contain a Z?" (answering "no"), while the other does not. But for the question "does this variant<X,Y> contain a X?", in both cases, "no" is still a valid answer. If your code doesn't expect "no" as an answer, it's broken, in either case.
My gut feeling is that "does this variant<X, Y> contain a Z" should be a compile time error, because it obviously doesn't contain a Z. (Of course less obvious when variant<X,Y> is spelled 'T'.) And because it *can* be a compile time error. In most C++ code, you need to go out of your way (eg dynamic_cast) to do type-stuff at runtime. Typically it is compile time. Beyond the strict/relaxed, is there a (compile time) way to ask "could this variant *ever* contain a Z" ? Broadly speaking: I'd like Boost to be brave and make breaking changes like this. The next step after boost:: is std::, and I'd like more trials and attempts at the boost level, because it is really hard to change once in std. Currently what I sometimes here in committee meetings is "but it has been this way in boost for years". But if boost is afraid to make changes, and the committee is afraid to change what comes from boost, then it means that std is just taking in whatever made it past the initial boost review (which is a good review process, but isn't meant to be the only gate to pass into std). Tony