Issue 559: numeric_limits (original) (raw)

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

559. numeric_limits

Section: 17.3.5 [numeric.limits] Status: CD1 Submitter: Martin Sebor Opened: 2006-02-19 Last modified: 2017-06-15

Priority: Not Prioritized

View other active issues in [numeric.limits].

View all other issues in [numeric.limits].

View all issues with CD1 status.

Discussion:

[limits], p2 requires implementations to provide specializations of thenumeric_limits template for each scalar type. While this could be interepreted to include cv-qualified forms of such types such an interepretation is not reflected in the synopsis of the<limits> header.

The absence of specializations of the template on cv-qualified forms of fundamental types makes numeric_limits difficult to use in generic code where the constness (or volatility) of a type is not always immediately apparent. In such contexts, the primary template ends up being instantiated instead of the provided specialization, typically yielding unexpected behavior.

Require that specializations of numeric_limits on cv-qualified fundamental types have the same semantics as those on the unqualifed forms of the same types.

Proposed resolution:

Add to the synopsis of the <limits> header, immediately below the declaration of the primary template, the following:

template class numeric_limits; template class numeric_limits; template class numeric_limits;

Add a new paragraph to the end of 17.3.5 [numeric.limits], with the following text:

-new-para- The value of each member of a numeric_limitsspecialization on a cv-qualified T is equal to the value of the same member of numeric_limits<T>.

[ Portland: Martin will clarify that user-defined types get cv-specializations automatically. ]