9

When using the line

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

in g++ 6.3.0, the compiler issues a warning stating:

warning: literal operator suffixes not preceded by '_' are reserved for future standardization

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

A similar warning is also issued in MSVS. However, clang 3.8.0 issues no such warning.

Since operator""s is defined by the standard for the chrono library shouldn't this not issue a warning since we are just importing the name and not defining one?

Angew is no longer proud of SO
  • 167,307
  • 17
  • 350
  • 455
NathanOliver
  • 171,901
  • 28
  • 288
  • 402
  • 2
    Warnings, unless they're mandatory diagnostics, are always a bit subjective. While I agree with you here, that just makes our a common opinion. – MSalters Jan 03 '17 at 13:23

1 Answers1

2

Arguably, the wording is clear enough on this—[over.literal]/1:

Some literal suffix identifiers are reserved for future standardization; see 17.6.4.3.5. A declaration whose literal-operator-id uses such a literal suffix identifier is ill-formed; no diagnostic required.

This can be interpreted as referring to (UDL operator) declarations whose "name" is a literal-operator-id—which of course excludes your case, since literal-operator-ids are unqualified. Same goes for [reserved.names]/2, where the “context”s are declarations of user-defined literal operators.

Columbo
  • 60,038
  • 8
  • 155
  • 203
  • No declaration "directly" contains a *literal-operator-id*, by this argument. That nonterminal is only used in two places (*template-id* and *unqualified-id*). – T.C. Jan 03 '17 at 19:01
  • @T.C. No, my argument was not about productions, but equivalence. The declaration does not name a *literal-operator-id*. – Columbo Jan 03 '17 at 21:28
  • Well, `operator""s` *is* a *literal-operator-id*, so I'm not sure I get the argument. – T.C. Jan 03 '17 at 23:05
  • @T.C. A *literal-operator-id* is never qualified. – Columbo Jan 03 '17 at 23:27
  • ...so? `std::literals::chrono_literals::` is the *nested-name-specifier* in the *using-declaration* and `operator""s` is a *literal-operator-id* used as an *unqualified-id* in that *using-declaration*. (s/using-declaration/using-declarator/g as needed to account for changes by your paper.) – T.C. Jan 03 '17 at 23:30
  • @T.C. "whose", to me, implies that the declaration's name *is* a *literal-operator-id*. Which coincides with the cases in which a new name is declared (and not an old one redeclared). – Columbo Jan 04 '17 at 00:03
  • @T.C. Okay, the topmost nonterminal is never a *literal-operator-id*, but it can directly reduce to one. My formulation was really bad here, my bad. – Columbo Jan 04 '17 at 00:07
  • For a *simple-declaration*, you'd need to go through *init-declarator* to *declarator* to *noptr-declarator* to *declarator-id* to *id-expression* to *unqualified-id* before you get to *literal-operator-id*. (And for *literal-operator-id*s in particular, they typically form a *noptr-declarator* that is itself part of a bigger *noptr-declarator* that uses the *noptr-declarator parameters-and-qualifiers* production.) For a *using-declaration* (or *-declarator*), *unqualified-id* is part of the production directly. So I'm not seeing an argument from the grammar here. – T.C. Jan 04 '17 at 00:12
  • @T.C. "Directly" as in "removing no terminals". Not "directly" as in "with one production". And yeah, I do see an argument from the grammar. Of course this is all using a liberal interpretation of the wording, and clarification could be appropriate. – Columbo Jan 04 '17 at 00:21
  • So, in `using foo::operator""s;`, you say dropping `foo::` is not OK even though the top-level production is "`using` `typename`(opt) *nested-name-specifier* *unqualified-id*;", but for `foo operator""s(unsigned long long);`, you say it's OK to drop the *parameters-and-qualifiers* `(unsigned long long)`, even though the top-level declarator in that declaration is the the whole `operator""s(unsigned long long)`. What am I missing, because I'm really not seeing how that argument works? – T.C. Jan 04 '17 at 00:27
  • @T.C. The top-level declarator, but not the top-level name. The top-level declarator can be anything and is rather uninteresting. – Columbo Jan 04 '17 at 00:30
  • "A *name* is a use of an *identifier* ([lex.name]), *operator-function-id* ([over.oper]), *literal-operator-id* ([over.literal]), *conversion-function-id* ([class.conv.fct]), or *template-id* ([temp.names]) that denotes an entity or label ([stmt.goto], [stmt.label])." ([basic]/4) That definition doesn't include *nested-name-specifier*s, so the "top-level name" can't be anything but `operator""s` in both cases. – T.C. Jan 04 '17 at 00:43
  • @T.C. No, I did not mean the formally defined term... I adjusted the answer to make my point clearer, anyway. – Columbo Jan 04 '17 at 11:14
  • I think you are trying too hard to read a "whose *declarator-id* is a *literal-operator-id*" into the current wording - the fact that you have to resort to a poorly-defined scary-quoted "name" is telling :) I think the answer is simply that the current wording, perhaps defectively, disallows OP's *using-declaration*. – T.C. Jan 05 '17 at 16:42
  • @T.C. Sounds agreeable. I'll file an issue and see what Mike has to say. – Columbo Jan 05 '17 at 19:16
  • 1
    @Columbo Any update? I was thinking about offering a bounty to get some more attention to this. – NathanOliver Aug 23 '17 at 13:42