From: "David Abrahams" <[EMAIL PROTECTED]> > "Paul Mensonides" <[EMAIL PROTECTED]> writes: > > > I do, however, agree that we need more support from the language for > > generic programming and some type of standardized API into the > > compiler's type system. And I definitely think that "undefined > > behavior" is unreasonable when the situation is easily diagnosable > > and not platform specific. > > I tend to agree on a "moral/aesthetic" level, but on a practical level > we have to tread carefully. The question, "can we just have an > operator which produces a compile-time constant value saying whether > its operand is a valid expression?" has come up a few times in the > committee. Each time, the implementors looked at their codebases and > said "oooh, that's really hard to do." I think the short form of the > reason is that C++ compilers generally don't have the ability to > recover from errors reliably. That may explain why your 2nd, 3rd, > 4th... diagnostic messages tend to be useless gibberish ;-)
But how does this apply to is_convertible<X, int> when a private X::operator int()? Or are you discussing something else? I see no reason to make that undefined behavior. It's either "false", "true" (Comeau says true BTW), "unspecified", or "ill formed, no diagnostic required" - in order of preference. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
