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

Subject: Re: [boost] [guidelines] why template errors suck
From: Eric Niebler (eric_at_[hidden])
Date: 2010-09-24 23:51:14

On 9/24/2010 9:37 PM, David Abrahams wrote:
> On Sep 24, 2010, at 8:41 PM, Eric Niebler wrote:
>> 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?

Haha! No, not at all. Let's rephrase the problem a bit. If we still had
C++0x concepts, what would the concept SpiritParser look like, such that
we could define spirit::qi::rule::operator= such that it required its
RHS to satisfy the SpiritParser concept? Would it be any more
illuminating that a simple wrapper around proto::matches<Expr,
SpiritGrammar>?

>> 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>.

Blech. Can C++0x SFINAE on expressions make this any nicer? The idea is
to be able to text expressions for well-formedness without causing a
compile error. Then we'd need a way to chain these expressions to make
lists of requirements. Maybe PP sequences consisting of valid
expressions? Is there a compiler that implements this yet so we can play
with it?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com