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

Subject: Re: [boost] [guidelines] why template errors suck
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-09-27 21:49:06

  AMDG

On 9/27/2010 3:15 PM, David Abrahams wrote:
> At Mon, 27 Sep 2010 14:13:26 -0700,
> Steven Watanabe wrote:
>> IMHO, the fundamental problem is that concepts guarantee
>> that if the template type-checks against the concept definition,
>> and the template arguments are models of the concept, then
>> there will be no type errors when the template is instantiated.
> Right in principle about how concepts work.  [Full disclosure: there
> are some corner cases where you can still have a type error but those
> are waaaaaaaay off in the obscure corners.  Concepts catch all the
> basic cases where you try to use an operation that's not guaranteed by
> the constraints.  However, I don't yet see what makes that the
> *fundamental* problem.]...
>
> ...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.

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

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

In Christ,
Steven Watanabe