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

Subject: Re: [boost] [guidelines] why template errors suck
From: David Abrahams (dave_at_[hidden])
Date: 2010-09-28 02:28:57

At Mon, 27 Sep 2010 18:49:06 -0700, Steven Watanabe wrote:
> 
> > ...but I'm not even sure there is a problem yet, even though I was one
> > of the first people to recognize that concepts clash with TMP as
> > practiced today.  The question is whether a different approach can
> > accomplish the same ends.  As far as I'm concerned, that's still an
> > open question.
> 
> Until someone finds a way, it might as well not be possible.

That might be a little like saying, "until someone demonstrates that
you can write the Sieve of Eratosthenes algorithm in BASIC, it might
as well not be possible."  At some level, all programming paradigms
are equivalent.

> >> This is a nice property, but the problem is that for template
> >> metaprogramming, the type /is/ the data.  The things that would
> >> normally be runtime errors become type errors.  

So here you're making an analogy by mapping the runtime world into the compile-time world.

> >> Thus, once
> >> you actually instantiate the template, there can be no errors
> >> whatsoever.  We don't apply this level of type-checking to
> >> runtime code, because it's simply impractical to guarantee.
> >
> > I think you mean we don't apply this level of runtime checking to
> > runtime code?
> 
> No, I really do mean type checking.

I don't see how that's consistent with your analogy.  When I map back
into the runtime world, why doesn't type checking become runtime
(value) checking again?

> If template A calls template B, then
> it won't compile unless the constraints
> on the parameters of A /guarantee/ that
> the parameters of B will be correct, right?
> Runtime checks would only verify that
> specific concrete parameters to B
> are correct.

And the above seems to continue to mix up the analogy in the same
way.  I must be totally misunderstanding you.

> > But isn't that exactly what contract programming is?
> > (http://en.wikipedia.org/wiki/Design_by_contract#Languages_with_native_support)?
> 
> I don't know that much about contract programming, but
> I thought that languages using it had to fall back to
> dynamic checks some of the time.

Exactly, all the time.  That's my point :-)

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