Должна ли используемая команда выдавать предупреждение при использовании зарезервированного идентификатора?

При использовании линии

using std::literals::chrono_literals::operator""s;

в g++ 6.3.0 компилятор выдает предупреждение:

предупреждение: суффиксы литеральных операторов, которым не предшествует '_', зарезервированы для будущей стандартизации

using std::literals::chrono_literals::operator""s;

Аналогичное предупреждение выдается и в MSVS. Однако clang 3.8.0 не выдает такого предупреждения.

Поскольку operator""s определяется стандартом для библиотеки хроно, не должно ли это не выдавать предупреждение, поскольку мы просто импортируем имя, а не определяем его?


c++ language-lawyer user-defined-literals using-directives reserved-words
person NathanOliver    schedule 03.01.2017    source источник
comment
Предупреждения, если только они не являются обязательной диагностикой, всегда немного субъективны. Хотя я согласен с вами здесь, это просто делает наше общее мнение.   -  person MSalters    schedule 03.01.2017

Ответы (1)


arrow_upward
2
arrow_downward

Возможно, формулировка достаточно ясна в этом[over.literal]/1:

Некоторые буквенные идентификаторы суффиксов зарезервированы для будущей стандартизации; см. 17.6.4.3.5. Объявление, чье идентификатор литерального-оператора использует такой литеральный суффиксный идентификатор, является некорректным; диагностика не требуется.

Это можно интерпретировать как обращение к объявлениям (оператора UDL), чье «имя» является идентификатором литерального-оператора, что, конечно, исключает ваш случай, поскольку идентификатор литерального-оператора s являются неквалифицированными. То же самое касается [reserved.names]/2, где контексты объявления определяемых пользователем литеральных операторов.

person Columbo    schedule 03.01.2017
comment
Ни одно объявление не содержит непосредственно идентификатор литерала-оператора с помощью этого аргумента. Этот нетерминал используется только в двух местах (template-id и unqualified-id). - person T.C.; 03.01.2017
comment
@Т.С. Нет, мой аргумент был не о произведениях, а об эквивалентности. В объявлении не указан литеральный-идентификатор-оператора. - person Columbo; 04.01.2017
comment
Ну, operator""s является идентификатором литерального-оператора, так что я не уверен, что понял аргумент. - person T.C.; 04.01.2017
comment
@Т.С. Идентификатор литерала-оператора никогда не уточняется. - person Columbo; 04.01.2017
comment
...так? std::literals::chrono_literals:: — это описатель вложенного имени в объявлении-использования, а operator""s — это идентификатор литерала-оператора, используемый как неполный -id в этом объявлении-использования. (s/using-declaration/using-declarator/g по мере необходимости для учета изменений в вашей статье.) - person T.C.; 04.01.2017
comment
@Т.С. чье, на мой взгляд, подразумевает, что имя объявления является идентификатором литерального-оператора. Что совпадает со случаями, когда объявляется новое имя (а не переобъявляется старое). - person Columbo; 04.01.2017
comment
@Т.С. Хорошо, самый верхний нетерминал никогда не является буквенным-идентификатором-оператора, но его можно напрямую свести к единице. Моя формулировка была действительно плохой здесь, моя плохая. - person Columbo; 04.01.2017
comment
Для простого объявления вам нужно пройти через init-declarator до declarator до noptr-declarator на идентификатор-декларатора на идентификатор-выражения на неквалифицированный-идентификатор, прежде чем вы доберетесь до буквенного-идентификатора-оператора. (В частности, для literal-operator-id они обычно образуют noptr-declarator, который сам является частью более крупного noptr-declarator. который использует продукцию параметров-и-квалификаторов noptr-declarator.) Для using-declaration (или -declarator) неквалифицированный -id является частью производства напрямую. Так что я не вижу здесь аргумента из-за грамматики. - person T.C.; 04.01.2017
comment
@Т.С. Прямо как при снятии клемм нет. Не прямо как в одной постановке. И да, я вижу аргумент из грамматики. Конечно, все это использует либеральную интерпретацию формулировки, и уточнение может быть уместным. - person Columbo; 04.01.2017
comment
Итак, в using foo::operator""s; вы говорите, что удаление foo:: недопустимо, даже если производство верхнего уровня using typename(opt) описатель вложенного имени неполный идентификатор;, но для foo operator""s(unsigned long long); вы говорите, что можно отбросить параметры-и-квалификаторы (unsigned long long), хотя декларатором верхнего уровня в этом объявлении является весь operator""s(unsigned long long). Что я упускаю, потому что я действительно не понимаю, как работает этот аргумент? - person T.C.; 04.01.2017
comment
@Т.С. Декларатор верхнего уровня, но не имя верхнего уровня. Декларатор верхнего уровня может быть любым и довольно неинтересным. - person Columbo; 04.01.2017
comment
имя — это использование идентификатора ([lex.name]), идентификатора-функции-оператора ([over.oper]), идентификатор литерала-оператора ([over.literal]), идентификатор-функции-преобразования ([class.conv.fct]) или идентификатор-шаблона< /i> ([temp.names]), который обозначает сущность или метку ([stmt.goto], [stmt.label]). ([basic]/4) Это определение не включает описатель вложенного имени, поэтому имя верхнего уровня не может быть ничем иным, как operator""s в обоих случаях. - person T.C.; 04.01.2017
comment
@Т.С. Нет, я не имел в виду формально определенный термин ... Я все равно скорректировал ответ, чтобы прояснить свою точку зрения. - person Columbo; 04.01.2017
comment
Я думаю, вы слишком усердно пытаетесь прочитать чей declarator-id является literal-operator-id в текущей формулировке - тот факт, что вам приходится прибегать к плохому -определенное страшное имя в кавычках говорит :) Я думаю, что ответ просто в том, что текущая формулировка, возможно, ошибочная, запрещает использование-декларации OP. - person T.C.; 05.01.2017
comment
@Т.С. Звучит приятно. Я зарегистрирую проблему и посмотрю, что скажет Майк. - person Columbo; 05.01.2017
comment
@Columbo Любое обновление? Я думал о том, чтобы предложить награду, чтобы привлечь к этому больше внимания. - person NathanOliver; 23.08.2017