<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 3923: The specification of numeric_limits doesn't clearly distinguish between implementation requirements
and user requirements</title>
<meta property="og:title" content="Issue 3923: The specification of numeric_limits doesn't clearly distinguish between implementation requirements
and user requirements">
<meta property="og:description" content="C++ library issue. Status: New">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue3923.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#New">New</a> status.</em></p>
<h3 id="3923"><a href="lwg-active.html#3923">3923</a>. The specification of <code>numeric_limits</code> doesn't clearly distinguish between implementation requirements
and user requirements</h3>
<p><b>Section:</b> 17.3.5.1 <a href="https://wg21.link/numeric.limits.general">[numeric.limits.general]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2023-04-15 <b>Last modified:</b> 2023-05-24</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#numeric.limits.general">active issues</a> in [numeric.limits.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#numeric.limits.general">issues</a> in [numeric.limits.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The wording of 17.3.5.1 <a href="https://wg21.link/numeric.limits.general">[numeric.limits.general]</a> seemingly has not been gone through a similar thorough 
rewording review which we performed in the past to clean-up the working draft as we did via the series of 
"Mandating" papers by Marshall Clow (<a href="https://wg21.link/P1458" title=" Mandating the Standard Library: Clause 16 - Language support library">P1458</a> - <a href="https://wg21.link/P1465" title=" Function optimization hint attributes: [[always_inline]], [[never_inline]]">P1465</a> and even more).
<p/>
17.3.5.1 <a href="https://wg21.link/numeric.limits.general">[numeric.limits.general]</a> contains several nowadays inappropriate wording forms, which don't 
distinguish well enough between requirements imposed on implementations (Where we shouldn't use "shall" wording 
in the ambiguous form of "Specializations shall be provided for each arithmetic type") and requirements imposed on
user types, this has also caused confusion as expressed in LWG <a href="lwg-active.html#3922" title="It's unclear whether numeric_limits can be specialized by users (Status: New)">3922</a><sup><a href="https://cplusplus.github.io/LWG/issue3922" title="Latest snapshot">(i)</a></sup>. It is "obvious"
that a program is intended to be allowed to provide program-defined specializations, but as 
LWG <a href="lwg-active.html#3922" title="It's unclear whether numeric_limits can be specialized by users (Status: New)">3922</a><sup><a href="https://cplusplus.github.io/LWG/issue3922" title="Latest snapshot">(i)</a></sup> points out, it is unclear how such a specialization is able to meet the requirement 
"(b) the specialization meets the standard library requirements for the original template" specified in 
16.4.5.2.1 <a href="https://wg21.link/namespace.std">[namespace.std]</a> p2.
<p/>
Another problem is the usage of the unclear wording "Non-arithmetic standard types", which should be replaced by
a more precise wording form.
<p/>
An additional problem is that we actually already <em>do</em> require an implementation to provide specializations
for the (library-provided) integer-class types (24.3.4.4 <a href="https://wg21.link/iterator.concept.winc">[iterator.concept.winc]</a>), so contrary to what p6
says, we already have at least one exception, where the library is required to specialize <code>numeric_limits</code>
for a non-arithmetic type. We should make that a bit clearer here as well.
<p/>
This issue is related to LWG <a href="lwg-active.html#3922" title="It's unclear whether numeric_limits can be specialized by users (Status: New)">3922</a><sup><a href="https://cplusplus.github.io/LWG/issue3922" title="Latest snapshot">(i)</a></sup> and paper <a href="https://wg21.link/P1841" title=" Wording for Individually Specializable Numeric Traits">P1841</a>.
</p>

<p><i>[2023-05-24; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll.
</p>



<p id="res-3923"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4944" title=" Working Draft, Standard for Programming Language C++">N4944</a>.
</p>

<blockquote class="note">
<p>
[<i>Drafting Note:</i> This wording would also solve LWG issue <a href="lwg-active.html#3922" title="It's unclear whether numeric_limits can be specialized by users (Status: New)">3922</a><sup><a href="https://cplusplus.github.io/LWG/issue3922" title="Latest snapshot">(i)</a></sup> under the assumption that
option <b>A</b> is intended] 
</p>
</blockquote>

<ol>
<li>
<p>Modify 17.3.3 <a href="https://wg21.link/limits.syn">[limits.syn]</a>, header <code>&lt;limits&gt;</code> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
// <i>17.3.5.1 <a href="https://wg21.link/numeric.limits.general">[numeric.limits.general]</a>, class template numeric_limits</i>
template&lt;class T&gt; class numeric_limits;

<ins>// <i>17.3.5.3 <a href="https://wg21.link/numeric.special">[numeric.special]</a>, numeric_limits specializations</i></ins>
template&lt;class T&gt; class numeric_limits&lt;const T&gt;;
template&lt;class T&gt; class numeric_limits&lt;volatile T&gt;;
template&lt;class T&gt; class numeric_limits&lt;const volatile T&gt;;

template&lt;&gt; class numeric_limits&lt;bool&gt;;
[&hellip;]
</pre>
</blockquote>
</li>

<li>
<p>Modify 17.3.5.1 <a href="https://wg21.link/numeric.limits.general">[numeric.limits.general]</a> as indicated:</p>

<blockquote>
<p>
-1- The <code>numeric_limits</code> class template provides a C++ program with information about various properties of
the implementation's representation of the arithmetic types.
<p/>
[&hellip;]
</p>
<blockquote class="note">
<p>
[<i>Drafting Note:</i> It is unclear whether the requirement in the following paragraph 2 is intended to apply to
program-defined specializations as well. Consider as an example a user-defined arithmetic-like type that provides 
arbitrary precision arithmetic which may require dynamic memory for certain object constructions. Is it invalid to specialize 
<code>numeric_limits</code> for such a type or may the program-defined specialization deviate from this requirement for 
at least some of its members?
<p/>
If we want to make this restriction relaxed for program-defined specializations, further wording would
be needed to give that permission] 
</p>
</blockquote>
<p>
-2- For all members declared <code>static constexpr</code> in the <code>numeric_limits</code> template, specializations shall 
define these values in such a way that they are usable as constant expressions.
<p/>
-3- For the <code>numeric_limits</code> primary template, all data members are value-initialized and all member functions
return a value-initialized object.
<p/>
[<i>Note 1</i>: This means all members have zero or <code>false</code> values unless <code>numeric_limits</code> is specialized for a 
type. &mdash; <i>end note</i>]
<p/>
-4- <ins>An implementation shall provide s</ins><del>S</del>pecializations <del>shall be provided</del> 
for each arithmetic type, both floating-point and integer, including <code>bool</code>.
The member <code>is_specialized</code> <del>shall be</del><ins>is</ins> <code>true</code> for all such specializations of 
<code>numeric_limits</code>.
<p/>
<del>-5- The value of each member of a specialization of <code>numeric_limits</code> on a cv-qualified type <code>cv T</code> shall 
be equal to the value of the corresponding member of the specialization on the unqualified type <code>T</code>.</del>
</p>
<blockquote class="note">
<p>
[<i>Drafting Note:</i> If we had introduced <code>numeric_limits</code> today we would likely have only allowed to
provide specializations for <i>cv</i>-unqualified program-defined types, but that ship has sailed long ago.
<p/>
Interestingly currently there doesn't exist a specification that defines under which situations the static member
<code>is_specialized</code> should be defined <code>true</code> or <code>false</code> (This touches LWG <a href="lwg-closed.html#205" title=" numeric_limits unclear on how to determine floating point types (Status: NAD)">205</a><sup><a href="https://cplusplus.github.io/LWG/issue205" title="Latest snapshot">(i)</a></sup>). 
The wording below does not attempt to improve that situation, but at least clarifies that its value may be different
from that of the primary template.
<p/>
Note that this proposed wording does &mdash; opposed to the approach of LWG <a href="lwg-active.html#3922" title="It's unclear whether numeric_limits can be specialized by users (Status: New)">3922</a><sup><a href="https://cplusplus.github.io/LWG/issue3922" title="Latest snapshot">(i)</a></sup> &mdash; not restrict 
that specializations can only be provided by program-defined types "emulating an arithmetic type", because that would 
break existing specializations and is also problematic in the light of the non-existing definition of that term.
<p/>
The below wording strategy gives permission to specialize <code>numeric_limits</code> only for non-array object types.
An alternative approach could make it a precondition instead to instantiate the template for non-array object types, 
for example.] 
</p>
</blockquote>
<p>
<ins>-?- A program may specialize the <code>numeric_limits</code> template for a program-defined non-array object type. 
Such a specialization is permitted to define a value for any static member that differs from what the primary 
template would have defined, as appropriate for that type.</ins> 
<p/>
<ins>[<i>Note</i>: It still has to meet the general requirements specified in subclause 
17.3.5.1 <a href="https://wg21.link/numeric.limits.general">[numeric.limits.general]</a> and subclause 17.3.5.3 <a href="https://wg21.link/numeric.special">[numeric.special]</a> &mdash; <i>end note</i>].</ins>
</p>
<blockquote class="note">
<p>
[<i>Drafting Note:</i> The following restriction is carefully drafted to ensure that a library has the freedom to provide such
specializations for "extended" types (That are not necessarily integer-class types). The restriction is intended to apply only 
to "official" (strict) C++ standard library types] 
</p>
</blockquote>
<p>
-6- <ins>An implementation shall not provide specializations for n</ins><del>N</del>on-arithmetic <del>standard</del> types
<ins>of the C++ standard library</ins>, such as <code>complex&lt;T&gt;</code> (29.4.3 <a href="https://wg21.link/complex">[complex]</a>)<ins>, unless specified
otherwise (e.g. for integer-class types, 24.3.4.4 <a href="https://wg21.link/iterator.concept.winc">[iterator.concept.winc]</a>)</ins><del>, shall not have 
specializations</del>.
</p>
</blockquote>
</li>

<li>
<p>Modify 17.3.5.3 <a href="https://wg21.link/numeric.special">[numeric.special]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting Note:</i> I have left the "shall" usage in p1, because this seems to be a requirement for program-defined
specializations as well. The second sentence of p1 is one of the funny ones which partially look like introductory
wording, but also seems to indicate requirements, albeit specified in an unusual way ("meaningful").
<p/>
The extra wording added after p2 below attempts to improve the wording situation caused by LWG <a href="lwg-defects.html#559" title="numeric_limits&lt;const T&gt; (Status: CD1)">559</a><sup><a href="https://cplusplus.github.io/LWG/issue559" title="Latest snapshot">(i)</a></sup>
and does that by following a similar approach as done in 22.4.7 <a href="https://wg21.link/tuple.helper">[tuple.helper]</a>.
] 
</p>
</blockquote>

<blockquote>
<p>
-1- All members shall be provided for all specializations. However, many values are only required to be meaningful
under certain conditions (for example, <code>epsilon()</code> is only meaningful if <code>is_integer</code> is <code>false</code>). 
Any value that is not "meaningful" shall be set to <code>0</code> or <code>false</code>.
<p/>
-2- [<i>Example 1</i>: 
<p/>
[&hellip;]
<p/>
&mdash; <i>end note</i>]
</p>
<blockquote><pre>
<ins>template&lt;class T&gt; class numeric_limits&lt;const T&gt;;
template&lt;class T&gt; class numeric_limits&lt;volatile T&gt;;
template&lt;class T&gt; class numeric_limits&lt;const volatile T&gt;;</ins>
</pre></blockquote>
<p>
<ins>-?- Let <code>NL</code> denote <code>numeric_limits&lt;T&gt;</code> of the cv-unqualified type <code>T</code>. Then the 
value of each member of these specializations of <code>numeric_limits</code> is equal to the value of the corresponding 
member of the specialization <code>NL</code>.</ins>
<p/>
-3- The specialization for <code>bool</code> <del>shall be</del><ins>is</ins> provided as follows:
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>






</body>
</html>
