<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>US-18: Removing User-Defined Literals</title>
<style type="text/css">
.ins {background-color:#A0FFA0}
.del {background-color:#FFA0A0; text-decoration: line-through;}
</style>
</head>

<body>
<h1>US-18: Removing User-Defined Literals</h1>

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

<h2>Introduction</h2>

<p>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.</p>

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

<ul>
  <li><b>User-defined literals are unimplemented</b>: 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.</li>
  
  <li><b>User-defined literals have no user experience</b>: 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 (<code>&lt;complex&gt;</code> and
  <code>&lt;chrono&gt;</code>, 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.</li>

  <li><b>User-defined literals conflict with C99</b>: C99 introduced
  hexadecimal floating point constants ("hexfloats", such as
  <code>0x1p+1</code>). 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.</li>

  <li><b>The cost of removing user-defined literals is low</b>: 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.</li>
</ul>

<p>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.</p>

<h2>Proposed Wording</h2>

<p>Modify section 2.5 [lex.pptoken] as follows:</p>

<ol start="1">
  <li>
  <pre><i>preprocessing-token:</i>
  <i>header-name</i>
  <i>identifier</i>
  <i>pp-number</i>
  <i>character-literal</i>
  <span class="del"><i>user-defined-character-literal</i></span>
  <i>string-literal</i>
  <span class="del"><i>user-defined-string-literal</i></span>
  <i>preprocessing-op-or-punc</i>
  each non-white-space character that cannot be one of the above
</pre>
  </li>

  <li>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 <span class="del">(including user-defined character literals)</span>, string literals <span class="del">(including user-defined string literals)</span>, preprocessing operators and punctuators, and single non-white-space characters that do not lexically match the other preprocessing token categories.</li>
</ol>

<p>Modify section 2.10 [lex.ppnumber] as follows:</p>

<ol start="1">
  <li>
  <pre><i>pp-number:</i>
  <i>digit</i>
  . <i>digit</i>
  <i>pp-number</i> <i>digit</i>
  <i>pp-number</i> <span class="del"><i>identifier-</i></span><i>nondigit</i>
  <i>pp-number</i> e <i>sign</i>
  <i>pp-number</i> E <i>sign</i>
  <i>pp-number</i> .
</pre>
  </li>
</ol>

<p>Modify 2.14.1 [lex.literal.kinds] as follows:</p>

<ol start="1">
  <li>There are several kinds of literals.
  <pre><i>literal:</i>
  <i>integer-literal</i>
  <i>character-literal</i>
  <i>floating-literal</i>
  <i>string-literal</i>
  <i>boolean-literal</i>
  <i>pointer-literal</i>
  <span class="del"><i>user-defined-literal</i></span>
</pre>
  </li>
</ol>

<p>Remove section 2.14.8 [lex.ext].</p>

<p>Modify 3 [basic] as follows:</p>

<ol start="8">
  <li>Two names are the same if
  <ul>
    <li>they are <i>identifier</i>s composed of the same character sequence, or</li>
    <li>they are <i>operator-function-id</i>s formed with the same operator, or</li>
    <li>they are <i>conversion-function-id</i>s formed with the same type, or</li>
    <li>they are <i>template-id</i>s that refer to the same class or function (14.4)<span class="del">, or</span></li>
    <li><span class="del">they are the names of literal operators (13.5.8) formed with the same literal suffix identifier</span>.</li>
  </ul>
</ol>

<p>Modify 5.1.1 [expr.prim.general]p1 as follows:</p>
<ol start="1">
  <li>
  <pre><i>unqualified-id:</i>
  <i>identifier</i>
  <i>operator-function-id</i>
  <i>conversion-function-id</i>
  <span class="del"><i>literal-operator-id</i></span>
  ~ <i>class-name</i>
  ~ <i>decltype-specifier</i>
  <i>template-id</i>
</pre>
  </li>
</ol>

<ol start="6">
  <li>An <i>identifier</i> is an <i>id-expression</i> provided it has been suitably declared (Clause 7). [<i>Note</i>: for <i>operator-function-id</i>s, see 13.5; for <i>conversion-function-id</i>s, see 12.3.2;
  <span class="del">for <i>literal-operator-id</i>s, see 13.5.8;</span> for <i>template-id</i>s, see 14.2. A <i>class-name</i> or <i>decltype-specifier</i> prefixed by ~ denotes a destructor; see 12.4.
  </li>
</ol>

<p>Remove section 13.5.8 [over.literal].</p>

<p>Remove section 17.6.3.3.5 [usrlit.suffix].</p>

<hr>
<address></address>
<!-- hhmts start --> Last modified: Mon Feb 28 06:52:59 PST 2011 <!-- hhmts end -->
</body> </html>
