On 28/09/10 13:20, Dave Abrahams wrote:
On Sep 28, 2010, at 4:33 AM, Mathias Gaunard<mathias.gaunard@ens-lyon.org> wrote:
I've done it and there was no particular problem. I just need to check the argument are input iterators and an unary function object taking the same value as the iterator value type and returning a boolean. (of course, by taking a particular value, I really mean taking something that can be converted from that particular value, and by returning a particular value I mean returning a type convertible to that value, but all of those implicit conversions are taken care of automatically by expressions)
All of that handwaving is exactly where the problem is.
I think I know where the problem is: you're confusing two distinct features that exist within the realm of concepts, and then comparing apples and oranges. The two features are: 1) the ability to check that a set of types model a concept, 2) the ability to check that the body of a function or class that requires certain parameters to be models of a particular concept is valid with the least amount of requirements that models of those concepts can provide. The former C++0x proposal provides both features. Boost.ConceptCheck provides both features as well, albeit using vastly different implementation techniques. For better error messages in libraries written within Boost, feature 1) is vastly more important than feature 2), since the only thing 2) does is ensuring the library is self-consistent (i.e. there is no need for these tests at all once the code has been properly debugged), while 1) ensures the user is rightly providing the preconditions required by the library. In Boost.ConceptCheck, 1) is achieved by defining a template function, whose body (a statement) contains all the expressions (and may contain statements too) that are necessary for the types to model the concept. If instantiating this function fails, which means the types do not model the concept, then you get a hard error you cannot catch at compile-time. What I'm suggesting is simply to replace that fairly dumb system of a function body by a set of expressions considered in an SFINAE context, which would allow to actually test whether the concept is being modeled or not without causing a hard error, which would be priceless in order to hugely improve the error messages. ConceptCheck also provides the mechanism of archetypes to implement feature 2), but that is quite unrelated, despite your insistence on talking about it. Yes, I agree that 2) helps in finding bugs in library code, such as possibly your find_if example, but it doesn't help at providing better error messages for the user assuming a bug-free library. It's a feature for the library developer, not its user. I'm sorry, but I still don't see how your comments are at all relevant.
When the computer is checking your work, you don't get that luxury ;-)
Right, but here we're not talking about the computer checking my work, but checking that what the user is giving me is what I'm expecting, so that I can tell him what he did wrong without throwing too much noise at thim.