On Fri, Oct 3, 2008 at 5:59 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Mathias Gaunard wrote:
This concept checking isn't really done at compile-time, so you cannot use its result with SFINAE. That's one of the major drawbacks of the concept checking library.
It is done at compile time. It just gives a compiles/doesn't compile answer rather than a boolean result that can be tested.
Is there any other option? I mean if t<x> is ill-formed, because the type x doesn't support some expression used in the template t, then is there some context where t could be instantiated with x without making the whole program ill-formed? I can't think of one. If there were such a context, then you might be able associate t<x>'s ill-formation with some boolean constant, and you would have a way to implement tests based on concept checking templates - a sort of concept-based type introspection for C++03, which would be way cool. However, without such a context, the best you can do is fail gracefully with informative compilation errors, which is the purpose of the concept checking library. This brings up an interesting question regarding the proposed concept language extensions for C++0x: If a function in an overload set requires a concept that its argument doesn't model but some other function in the set accepts the argument, does overload resolution succeed? In other words, does the proposal support Concept Requirement Failure Is Not An Error? CRFINAE. ;-) Daniel Walker