US-18: Removing User-Defined Literals

Author: Douglas Gregor
Contact: doug.gregor@gmail.com
Organization: Apple
Date: 2011-02-28
Number: N3250=11-0020

Introduction

This proposal recommends the removal of user-defined literals (N2765) from the C++0x working paper, per National Body comment US-18. The author believes that user-defined literals should be considered as a feature for future language standards, but that the risks associated with keeping this feature in the C++0x working paper far outweigh the benefits.

User-defined literals should be removed from the C++0x working paper for the following reasons:

• User-defined literals are unimplemented: Without implementation experience, we have no reasonable assurance that the feature is implementable in all compilers or can work as the authors intended. Implementing a feature is the only way to ensure that the specification is sound, and has always resulted in changes and improvements to the specification.
• User-defined literals have no user experience: Since there are no implementations of this feature, there are no users and has been no feedback about usefulness of the feature. Most glaring is the complete lack of user-defined literals in the C++0x Standard Library, which contains a number of data types that would surely benefit from this feature (<complex> and <chrono>, for example). This may stem from a lack of interest, design problems that make this feature unsuitable for use in the standard library, or merely a pragmatic desire to not introduce features in the library that cannot be tested with an implementation. Regardless, we have no experience using this feature to write C++ code, nor are we giving users any guidance regarding how they should write C++ code with this feature.
• User-defined literals conflict with C99: C99 introduced hexadecimal floating point constants ("hexfloats", such as 0x1p+1). However, there is a conflict between C99 hexfloats and the user-defined literal operator "p", which forces compilers to pick one or the other interpretation. At least three compilers (GCC, EDG when emulating GCC, Clang) support hexfloats in C++ already, and will be affected by this conflict. The library prohibition on user-defined literal suffixes that don't start with an underscore ([usrlit.suffix]) is a weak attempt at addressing this problem, but the fundamental issue remains: there is a syntactic conflict in a proposal that claims to increase compatibility with C99. Indeed, user-defined literals may have the ability to improve compatibility if, for example, the C++0x Standard Library contained user-defined literals that emulate C99 hexfloats.
• The cost of removing user-defined literals is low: There is no code, no language wording, and no Standard Library construct that depends on user-defined literals, and the wording for user-defined literals is fairly self-contained, making the removal of this feature simple. Moreover, since this feature has not been implemented in the more than two years since it was accepted (and proposals to use it in the Standard Library have not been forthcoming), it seems unlikely that removal will affect any National Body votes or the user community at large.

Overall, we have a feature that has no implementation or usage experience, conflicts with existing practice in the C99 standard without providing the promised compatibility improvements.

Proposed Wording

Modify section 2.5 [lex.pptoken] as follows:

1. preprocessing-token:
     header-name
     identifier
     pp-number
     character-literal
     user-defined-character-literal
     string-literal
     user-defined-string-literal
     preprocessing-op-or-punc
     each non-white-space character that cannot be one of the above
   

2. A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6. The categories of preprocessing token are: header names, identifiers, preprocessing numbers, character literals (including user-defined character literals), string literals (including user-defined string literals), preprocessing operators and punctuators, and single non-white-space characters that do not lexically match the other preprocessing token categories.

Modify section 2.10 [lex.ppnumber] as follows:

1. pp-number:
     digit
     . digit
     pp-number digit
     pp-number identifier-nondigit
     pp-number e sign
     pp-number E sign
     pp-number .
   

Modify 2.14.1 [lex.literal.kinds] as follows:

1. There are several kinds of literals.

   literal:
     integer-literal
     character-literal
     floating-literal
     string-literal
     boolean-literal
     pointer-literal
     user-defined-literal
   

Remove section 2.14.8 [lex.ext].

Modify 3 [basic] as follows:

8. Two names are the same if
   • they are identifiers composed of the same character sequence, or
   • they are operator-function-ids formed with the same operator, or
   • they are conversion-function-ids formed with the same type, or
   • they are template-ids that refer to the same class or function (14.4), or
   • they are the names of literal operators (13.5.8) formed with the same literal suffix identifier.

Modify 5.1.1 [expr.prim.general]p1 as follows:

1. unqualified-id:
     identifier
     operator-function-id
     conversion-function-id
     literal-operator-id
     ~ class-name
     ~ decltype-specifier
     template-id
   

6. An identifier is an id-expression provided it has been suitably declared (Clause 7). [Note: for operator-function-ids, see 13.5; for conversion-function-ids, see 12.3.2; for literal-operator-ids, see 13.5.8; for template-ids, see 14.2. A class-name or decltype-specifier prefixed by ~ denotes a destructor; see 12.4.

Remove section 13.5.8 [over.literal].

Remove section 17.6.3.3.5 [usrlit.suffix].