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

Subject: Re: [boost] [guidelines] why template errors suck
From: Eric Niebler (eric_at_[hidden])
Date: 2010-09-26 08:55:40

On 9/25/2010 1:24 PM, David Abrahams wrote:
> 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?

No. rule::operator= expects SpiritParser to be a strongly-typed tree.
operator= walks that tree and converts it to a recursive descent parser.
The tree conforms to a grammar that is easily expressible in Proto, but
I wouldn't know how to express such a constraint with concepts.

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

Why do you doubt it's possible? If there are template constraints not
practically expressible in concepts, then aren't concepts broken?

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

I was never convinced that valid expressions are the wrong approach.

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