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

[Doug Gregor]

On Mon, Apr 25, 2011 at 1:51 PM, James Widman <widman at gimpel.com> wrote:
>
> On 25 Apr 2011, at 13:40, John McCall wrote:
>
>> 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. :)
>
> <nod>
>
> Incidentally, the "implementation" that I work on is not really an implementation; so, among other things, we don't actually need to generate mangled names, so this would not even apply to us.
>
> But having said that, I prefer a mangling rule that just uses a translation of the raw token sequence for the following reasons:
>
> 1)
> It's probably harder to implement that rule incorrectly.  (For example, the implementor does not need to consider whether a call was written as foo(t) vs. (foo)(t) because you don't even need to think in terms of whether the expression involves a call.)

I think the situation is rather the opposite: it takes quite a bit
more effort for an implementation to track exactly how a declaration
was written in the source code, since that information hasn't
traditionally been required for compilation. I, personally, would tend
toward resolving whatever we can resolve and mangling based on that.

> 2)
> Suppose you have two /expression/s that are functionally equivalent but not equivalent and they both involve the same template parameters.  If the language rules ever change such that they are no longer functionally equivalent, the mangling rule would not need to change.

This seems like an unlikely language direction to me.

  - Doug