Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk