Почему все еще необходимо устранить двунаправленный тип зависимого типа с именем типа в RHS использующего оператора?

Question

Я очень хорошо знаю, почему нужно использовать typename для зависимых типов, так как компилятор может не иметь возможности устранить неоднозначность между типом и объявлением переменной, когда он видит что-то вроде T::type, см., Например, this answer для отличного объяснения. TL; DR: в выражении типа T::type * x; компилятор не может «знать», является ли T::type типом или, возможно, переменной, объявленной в определенной специализации для T.

Однако, в чем-то вроде

using type = T::type; 

нет ничего неоднозначного. IMO, T::typeвсегда следует анализировать как тип, так как он является частью RHS инструкции using. Тем не менее, мы по-прежнему необходимо использовать typename здесь (по крайней мере, в соответствии с НКУ и лязгом),

using type = typename T::type; 

Live on Coliru, gcc Live on Coliru, clang

Visual C++ seems to accept the code без typename, однако я не слишком много веры в компиляторе, который полностью соответствует стандарту (на самом деле он имеет множество нестандартных расширений, например, привязка значений r к неконстантным ссылкам).

Вопрос: Есть ли причина, по которой это не является исключением из правила typename в C++ 11 и более поздних версиях?

Answer 1

Тип аргумента шаблона T не позволяет и неявно нести с собой внутренние компоненты. таким образом, тип T :: является принципиально новым типом, когда компилятор просматривает необоснованный шаблон, поэтому необходимо объявить новое имя типа «T :: type».

К сожалению, я думаю, что этот вопрос останется с нами до тех пор, пока стандарт не включит полнофункциональные концепции.

Answer 2

Нет веской причины. Как ralismark said, в этом году обсуждался документ (для C++ 20, а не 17!). Есть проблемы, но и контрапункт:

1. Это можно рассматривать как сделать язык менее регулярным (как codeshot said), но новая идея состоит в том, что неоднозначности typename станет достаточно редко, чтобы иметь почти последовательности в других направление. (Как has been said, был уже исключительный случай в виде имен базового класса.)
2. Он мог исключить возможные расширения (как T.C. reported), но расширения могут иметь свои собственные значения, а не обременять общий случай.

Документ имеет сильную поддержку, и новые правила, вероятно, появятся в рабочем проекте через несколько месяцев.