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

Subject: Re: [boost] [guidelines] why template errors suck
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-03 21:30:02

At Mon, 04 Oct 2010 00:39:41 +0100,
Mathias Gaunard wrote:
> 
> 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.

No problem at all; just trying to save time.

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

That is not "works in C++03," that's "some C++03 compilers have an
extension for it."  I tried this with gcc 4.5.1 and it still couldn't
detect copyability without causing an error:

-----
template <unsigned> struct fu {};
template <class T> T make();

template <class T>
char* copyable(T*, fu< sizeof(T(make<T>())) >* = 0);

int copyable(...);

struct X
{
 private:
    X(X const&);
};

char* test0 = copyable((int*)0);  // works, proving int is copyable
int test1 = copyable((X*)0);      // I get an error here
-----

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

The question is whether it's possible to do much better.

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

I'm not sure we can do much better with proto unless we have decltype.

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

Dunno.

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

Feel free to make incremental improvements, if you think you can.

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

Since I started the original argument, don't I get to decide what
counts as a shift?

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

Sorry, been too busy to go into detail.

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