Re: [boost] [guidelines] why template errors suck

Subject: Re: [boost] [guidelines] why template errors suck
From: David Abrahams (dave_at_[hidden])
Date: 2010-09-24 21:37:45

On Sep 24, 2010, at 8:41 PM, Eric Niebler wrote:
> 
> On 9/24/2010 8:22 PM, Robert Ramey wrote:
>> Eric Niebler wrote:
>>> This is borderline self-promotion and I fretted posting this. But we a
>>> community of advanced C++ library developers and I'd really like
>>> feedback about these issues. And they really do involve Boost library
>>> development. If we could reach agreement about these techniques, we
>>> might want to integrate them into Boost's coding guidelines.
>>> 
>>> http://www.reddit.com/r/programming/comments/diddg/expressive_c_why_template_errors_suck_and_what/
>>> 
>>> Comments?
>> 
>> would all this boil down to the following guidlines.
>> 
>> a) All template libraries should use boost::concepts ?
> 
> Certainly Concept_check or something like it has a big role to play in
> this. But I wouldn't know how to use Concept_check to verify that an
> expression template matches a grammar, for instance. It's not the whole
> story. Though perhaps I don't know enough about the concept_check
> library to see how it can apply to proto expressions and grammars.
> Suggestions?

You'd need to describe adherence to the grammar as a concept.  Ultimately, Concept_check relies on the same stuff as BOOST_MPL_ASSERT_MESSAGE: causing a hard error when the concept isn't satisfied.  And it does that by crudely attempting to exercise all the compile-time elements of a concept's requirements.  So I think your concept would probably end up looking something like:

template <class Expr>
struct Grammatical
{
    static_assert(
        proto::matches<Expr, MyGrammar>::value, 
        "The expression  does not match MyGrammar");
};

Not very illuminating, is it?

> Also, I would prefer C++0x static_assert to the concept_check macros
> because the error messages can be much nicer. I think the answer is that
> the concept_check library badly needs a C++0x makeover.

The real challenge would be making it easy to write new concepts.  Right now the usage requirements are simple to state, but if you wanted static_assert to fire, 
we'd need to use checks that don't cause errors, e.g. instead of:

        same_type(*i++,v);  // postincrement-dereference returning value_type

you'd have to write something like:

    static_assert( 
        has_postincrement<InputIterator>::value, "not postincrementable");
    static_assert( 
        has_postincrement_deref<InputIterator>::value, "not dereferenceable");
    static_assert( 
        is_same< 
            postincrement_deref<InputIterator>::type, InputIterator::value_type
        >::value,
       "postincrement dereference doesn't return value_type");

Well, in all, I guess I like the rigor but it's not very compatible with the loosey-goosey C++03 way of specifying concepts <pines for real concept support>.

--
Dave Abrahams
BoostPro Computing
http://boostpro.com