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 17:13:26

  AMDG

On 9/27/2010 12:57 PM, Eric Niebler wrote:
> On 9/27/2010 3:01 PM, David Abrahams wrote:
>> Also there's no real-world scenario that can benefit from it.  There's
>> nothing that OR constraints could express that couldn't also be
>> expressed with concept_maps, and once you got inside the constrained
>> template you wouldn't be able to use any operations that aren't in the
>> intersection of the constraints (remember that template bodies need to
>> typecheck against their constraints).
> The /intersection/? This seems like a real problem then, doesn't it? I
> want to say that a SpiritParser is a SpiritNode<plus>  OR a
> SpiritNode<right_shift>  OR a SpiritNode<terminal>  (the plus and
> right_shift concepts being recursively defined in terms of SpiritParser,
> the terminal concept having little more than a value_type typedef and a
> member), the intersection of all those concepts would have exactly
> nothing. So I couldn't do anything with it from a constrained context.
> What have I missed? How is the SpiritParser concept you've defined above
> supposed to be used?

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

In Christ,
Steven Watanabe