Boost logo

Boost :

Subject: Re: [boost] [guidelines] why template errors suck
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2010-09-28 12:23:05

On 28/09/10 13:20, Dave Abrahams wrote:
> On Sep 28, 2010, at 4:33 AM, Mathias Gaunard<mathias.gaunard_at_[hidden]> 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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at