Boost logo

Boost :

Subject: Re: [boost] [guidelines] why template errors suck
From: Eric Niebler (eric_at_[hidden])
Date: 2010-09-27 18:00:11


On 9/27/2010 5:13 PM, Steven Watanabe wrote:
> 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.

Thanks, Steven. So if I understand you correctly, you're of the opinion
that using C++0x concepts to type-check Spirit's templates (or other
Proto-based EDSL, or even metaprograms in general) is not going to work?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

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