> On Dec 2, 2014, at 5:42 PM, Richard Smith <[email protected]> wrote:
>
> On 2 December 2014 at 16:34, John McCall <[email protected]
> <mailto:[email protected]>> wrote:
>> On Dec 2, 2014, at 3:51 PM, Richard Smith <[email protected]
>> <mailto:[email protected]>> wrote:
>> On 2 December 2014 at 13:58, John McCall <[email protected]
>> <mailto:[email protected]>> wrote:
>> Hmm. I’d prefer not to hard-code an order dependence, because I think it’s
>> likely that the committee will eventually weaken the rules about where packs
>> can appear in parameter lists (e.g. to allow templates to pull arguments off
>> the end instead of the beginning).
>> So I think we either need to do what EDG does and heroically match later
>> arguments which have to be part of the pack — which may or may not work
>> equally well with future pack-placement rules — or pull back and say we’re
>> completely blocked by the existence of dependent pack expansions.
>>
>> EDG's approach is impossible to follow in some cases, such as:
>>
>> template<int A, short B, int C = 0> struct X {};
>> template<int ...N> void f(X<N..., 5>) {}
>> template void f<0>(X<0, 5>);
>> template void f<0, 1>(X<0, 1, 5>);
>>
>> (EDG rejects this, which I suspect is related to their eager analysis of
>> template arguments.)
>
> Okay. So are we comfortable with a simple rule that dependent pack
> expansions always make a template argument “dependent” in the sense I
> described?
>
> Is the suggestion that the entire template argument list becomes dependent if
> it contains a dependent pack expansion[1]? Or that template arguments at or
> after a dependent pack expansion become dependent? The latter is what
> everyone is currently doing; the former would be more future-proof but is an
> ABI break for all implementations I surveyed.
I’m just trying to come up with a well-defined rule. The current compiler
behavior appears to be directly exposing implementation decisions about when to
type-check template arguments against their parameters. EDG’s efforts are
well-intentioned and could certainly be followed without actually getting the
case you described wrong; conversely, why should some amount of
known-to-be-incomplete checking be required just to produce a correct mangling?
As far as I know, we generally don’t require any expressions in a function
template signature to be type-checked except in specific circumstances which
only apply if they’re instantiation-independent.
A rule of “use type-checked template arguments only if you can type-check all
the template arguments” makes the most sense to me, but it might be too
compatibility-breaking.
>> Here, GCC mangles f<A> and g<A> the same, even though one of them refers to
>> A as a class template, and the other refers to A as a non-template
>> injected-class-name. That might just be a GCC bug, though; its diagnostics
>> suggest that it thinks the template argument for f is A<int> rather than A.
>
> Definitely seems like a GCC bug. I hope Clang mangles the first as a
> reference to A and the second as the type A<int>?
>
> Clang does not implement injected-class-name template-argument duality, so it
> rejects.
Ah, okay.
John.
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
