On 13/09/2010 18:03, Daniel Walker wrote:
What I had in mind for the example is to illustrate the feasibility of a concept checking library that issues substitution failures rather than compilation errors when a type doesn't model a required concept. This would provide an API to restrict the compiler such that it considers only overloads for which the argument types meet the requirements of the function body. It might be possible to approximate the functionality of the "requires" keyword from ConceptC++ without requiring language extensions to C++0x. But this would be a long-term, general solution. In the mean time, I'm not sure what to do about your immediate problem.
Right, I've been saying that for a while. Concepts being dropped from C++0x is not such a big deal since SFINAE can do the job anyway. I've had plans for a while to rewrite Boost.ConceptCheck to do that, but unfortunately the interface would need to change, because Boost.ConceptCheck allows arbitrary statements instead of just expressions. However, SFINAE has a few caveats compared to concepts: - public/private/protected access control is done after template substitution, so you can get a hard error because of these - it doesn't provide structural subtyping, i.e., it doesn't order the overloads by quality of match. But in practice this isn't much of a problem because you want to define concepts nominally anyway, and when you do that you can specify what you refine. - it doesn't support retroactive modelling, but that kind of thing can be done with traits.