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