[cxx-abi-dev] N4198 and mangling for member pointer template arguments

[John McCall]

> On Dec 2, 2014, at 5:42 PM, Richard Smith <richardsmith at google.com> wrote:
> 
> On 2 December 2014 at 16:34, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> On Dec 2, 2014, at 3:51 PM, Richard Smith <richardsmith at google.com <mailto:richardsmith at google.com>> wrote:
>> On 2 December 2014 at 13:58, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20141202/a3da8ee7/attachment.html>