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

Subject: Re: [boost] [guidelines] why template errors suck
From: David Abrahams (dave_at_[hidden])
Date: 2010-09-25 13:24:27

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

That's easy to answer; just look at the operations that operator= et. al expect of such a type. Wouldn't SpiritParser just be some simple refinement of Callable?

> Would it be any more
> illuminating that a simple wrapper around proto::matches<Expr,
> SpiritGrammar>?

If you want to apply concepts to this stuff (and I'm not sure whether it's really possible), you have to go back to the classic Generic Programming Process: look at concrete algorithms, lift out common requirements, cluster into concepts, etc.

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

Maybe.

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

Yeah, it would involve a bunch of PP stuff.

> Is there a compiler that implements this yet so we can play
> with it?

According to http://gcc.gnu.org/projects/cxx0x.html that stuff came in with GCC 4.4

But IMO this is all beside the point.  The truth is that valid expressions are the wrong way to describe concepts, for reasons you and I have discussed in the past.  The now-comatose C++ concepts proposal had it right.

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