On 20/12/2021 23.49, Hani Deek via Std-Proposals wrote:
>> I'd like to understand more how the modified name lookup rules are
>> supposed to work, with special attention to backward compatibility
>> concerns, i.e. how existing code might change meaning under the new
>> rules.
>
> I have not developed a full proposal. What I say here are just preliminary thoughts.
> We may introduce a rule whereby an ambiguous name 'Foo' (that names both a namespace and a class template) will be considered a namespace name in contexts where it cannot be a template name, e.g. if it is followed by :: and not possibly an injected class name. In other contexts, Foo will be considered a template name or an injected class name, per the current rules.
> That rule should not cause backward compatibility issues.
> Internally, the compiler can assign different names to the namespace Foo and the class template Foo.
>
> Like I said, I don't think such rules can be adopted.

So, we're left with a dead proposal, then?

> If someone will make a proposal of this sort, the proposal should aim to do more important things, such as ridding us of the unnecessary 'template' keyword with dependent names.
>
> I believe that the vast majority of cases where a dependent name is currently required to be preceded by 'template' do not really require the use of that keyword.
>
> Consider the following:
>
> template<typename>
> struct A;
>
> template<typename T>
> auto foo() { return A<T>::B<int>; }
>
> What are the chances that 'B' is not a template name? The answer is zero. There is no way that 'B' in this case is not a template name. The operator < cannot have 'int' or any other type name as an operand.

This has been done to the extent the grammar is unambiguous:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0634r3.html

Jens