[cxx-abi-dev] namespace-qualified unresolved-names

[John McCall]

On Apr 25, 2011, at 9:59 AM, James Widman wrote:
> On 24 Apr 2011, at 02:22, John McCall wrote:
>> 1. When mangling a namespace qualifier for an unresolved-name,
>> should we mangle the full namespace path or just what was written?
>> namespace outer {
>>   namespace ns { ... }
>>   template <typename T> auto forward_foo(T t) -> decltype(ns::foo(t));
>>   // sr2nsE3foo or sr5outer2nsE3foo or gssr5outer2nsE3foo ?
>> }
> 
> I think the answer is "just what was written" (i.e., you use the raw sequence of tokens) because of 14.4 [temp.type] p2:
> 
>        If an expression e involves a template parameter,
>        decltype(e) denotes a unique dependent type. Two such
>        /decltype-specifiers/ refer to the same type only if their
>        /expression/s [grammar term] are equivalent (14.5.6.1).
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        [Note: however, it may be aliased, e.g., by a
>        typedef-name. end note ]
> 
> So the type given by:
> 
>   decltype(inner::foo(t))
> 
> ... is not the type given by:
> 
>   decltype(outer::inner::foo(t))
> 
> ... because the /expression/s are different (because the token sequences are different).

I agree that [temp.over.link] gives us the right to mangle these
differently if we want:  they're "functionally equivalent" but not
"equivalent", and so the behavior is undefined.  That doesn't
actually mean we have to distinguish them — this is our cover
for not mangling parentheses in general — but I have no real
complaint with doing so.  I just want there to be a rule. :)

>> The 'gs' does not seem to be useful in the case of a non-member
>> unresolved-name with a qualifier.
>> 
>> 2. Should we look through template aliases?
>> namespace alias = ns;
> 
> (That's a namespace alias [namespace.alias], although it's good to consider namespace aliases in addition to alias templates [temp.alias].)

...wow.  I really did mean to say "namespace alias", but somehow
I seem to have used "template alias" consistently.  Someone's been
working on them in Clang, so they're on my mind...

John.