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

Subject: Re: [boost] [guidelines] why template errors suck
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2010-10-04 13:31:12

On 04/10/10 11:22, David Abrahams wrote:
> At Mon, 04 Oct 2010 09:48:12 +0100,
> John Bytheway wrote:
>>
>> On 04/10/10 00:39, Mathias Gaunard wrote:
>>> On 28/09/2010 19:14, David Abrahams wrote:
>>>> Unfortunately, without real concepts we may not be able to do better,
>>>> because the pseudo-signature approach inserts type conversions that
>>>> we'd have to write by hand.  Now here's an interesting thought: write
>>>> a library using TMP that generates "concept wrappers" that will force
>>>> the necessary conversions.  Would require heavy use of rvalue
>>>> references to avoid needless copies.  Hmm...
>>>
>>> A crazy idea if you want to be TMP-heavy: maybe you could represent the
>>> valid expressions with Proto and infer an archetype from these.
>>>
>>> This could provide better syntax than the "operator_increment" thing you
>>> suggested in some other part of the thread.
>>
>> Indeed, I already had that idea, and I implemented a proof-of-concept.
>> I guess my posts went unnoticed in this huge sprawling thread.  See:
>>
>> http://article.gmane.org/gmane.comp.lib.boost.devel/208946
>> http://article.gmane.org/gmane.comp.lib.boost.devel/208996
>>
>> As you suggest, I think it should be possible to use a single definition
>> to check models against concepts, make archetypes, and do concept-based
>> overloading.  What I'm not sure is whether (a) it's worthwhile to do it,
>> and (b) whether it would be worth attempting the more ambitious "concept
>> wrappers" idea Dave suggests above.
> 
> One step at a time, maybe.  What you did looks good.  One thing I
> should point out, though, is that SFINAE-controlled overloading and
> good error messages from concept checks are not exactly compatible.

Yes, I noticed that.

> I
> think you need to leave off the SFINAE on the overloads with the
> least-refined concepts, somehow, if you want something better than a
> ridiculous list of non-matching candidates.

I would imagine that when one is doing concept-based dispatching one
would use an outer function which asserted conformance to the
least-refined concept, and then forwarded to various implementations for
different refinements (e.g. essentially what happens now with iterator
traits).  That should avoid this particular issue.

More problematic (I think) is that the SFINAE-based error messages are
probably never going to be as good as from e.g. Boost.ConceptCheck,
because they will have to go through some translation layer to make them
non-fatal and thus won't be in the 'native language' of compiler errors
and won't be closely tied to the source location where the requirements
are defined.

John Bytheway