
AMDG On 9/27/2010 11:28 PM, David Abrahams wrote:
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.
You, yourself, just said that it was an open question. Would you describe writing the sieve of Eratosthenes in BASIC as an open question? FWIW, I'm sure that there /exists/ another way to do the things that we do now with TMP, which will work with concepts. I'm not at all convinced that it won't have more problems than current TMP.
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.
Exactly.
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?
This would be true without C++0x concepts. Half of concepts is type checking the bodies of templates when they are defined. These checks are equivalent to ordinary type checking in the runtime world. The problem is that concepts force all checks into this realm.
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. Exactly, all the time. That's my point :-)
This is equivalent to throwing static_assert all over the place, which I'm all in favor of. It isn't equivalent to C++0x concepts, if I understand them correctly. In Christ, Steven Watanabe