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

Subject: Re: [boost] [guidelines] why template errors suck
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2010-10-03 19:39:41

On 28/09/2010 19:14, David Abrahams wrote:

> Just for the record, I wrote the current implementation of
> Boost.ConceptCheck, so I do understand how it works.

My bad, please excuse my crude inaccurate explanation then.

>> What I'm suggesting is simply to replace that fairly dumb system of a
>> function body by a set of expressions considered in an SFINAE
>> context,
>
> The current system isn't dumb for C++03; it's the best you can do for
> many checks.  There's no way to check for copy-constructibility, for
> example, without causing a compile-time error when the check fails.

SFINAE extended to expressions works in C++03 too, albeit it is not a 
mandatory feature and was implemented in most compilers only recently. 
(GCC didn't support it before mostly due to mangling issues)

>> which would allow to actually test whether the concept is being modeled
>> or not without causing a hard error, which would be priceless in order
>> to hugely improve the error messages.
>
> I'm not convinced it would be a _huge_ improvement.  You might be able
> to get rid of one level of instantiation stack, but AFAICT that's not
> a huge difference.

 From my own experience using ConceptCheck, you still get a lot of 
unwanted errors.
My experience did involve using ranges, iterators and their associated 
concepts, with archetypes used in the concept body.

Thinking about it, since I needed to use archetypes to define my 
concept, an unified solution might be nice indeed.

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

> Depends what you think the question is.  IMO if we're going to talk
> about a library redesign for BCCL it should consider whether we can
> express concepts more effectively.

But is someone thinking and actively working on a nice universal solution?

Also, while time is spent thinking of that, the problem of bad error 
messages keeps on affecting more code.

> Maybe that's all you're talking about, but it's never been all I'm
> talking about.  Personally I'm not interested in a discussion that
> doesn't at least attempt to address the other half of the problem.

I didn't realize you shifted the original argument that much.
Surely the couple of successive messages that gave no more explanations 
than "try it and you will see that approach is wrong" didn't help 
clarifying that up.