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

[James Widman]

On 25 Apr 2011, at 17:21, Doug Gregor wrote:

> 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.

Ah.

(It probably would be straightforward for a token-cache implementation, but I forgot about the tree implementations.  I see your point.)

James Widman  
-- 
Gimpel Software 
http://gimpel.com