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

Subject: Re: [boost] [guidelines] why template errors suck
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-09-28 13:12:29

  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_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 :-)

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