AMDG On 9/27/2010 3:15 PM, David Abrahams 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
At Mon, 27 Sep 2010 14:13:26 -0700, Steven Watanabe wrote: 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_suppor...
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