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
> >> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk