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

2730. numeric_limits primary template definition

Section: 17.3.5 [numeric.limits] Status: Open Submitter: Richard Smith Opened: 2016-06-09 Last modified: 2023-04-18

Priority: 3

View other active issues in [numeric.limits].

View all other issues in [numeric.limits].

View all issues with Open status.

Discussion:

I've received this report at the project editor mail alias, and it seems like it may be worthy of a LWG issue:

I recently had this problem:

• I was storing data in a vector of __uint128_ts
• I used a sorting library which used numeric_limits<T>::max() as a sentinel value
• GCC's libstdc++ provides a numeric_limits specialisation for that type, but
• Clang's libc++ does not.

This broke the sorting for me on different platforms, and it was quite difficult to determine why. If the default numeric_limits didn't default to 0s and false values (18.3.2.4 of N4582), and instead static_asserted, causing my code to not compile, I would have found the solution immediately.

I know that __uint128_t is non-standard, so neither GCC nor Clang is doing the wrong thing nor the right thing here. I could just submit a patch to libc++ providing the specialisations, but it doesn't fix the problem at its core.

I am wondering, what is the rationale behind the defaults being 0 and false? It seems like it is inviting a problem for any future numeric types, whether part of a library, compiler extension, and possibly even future updates to C++'s numeric types. I think it would be much better to prevent code that tries to use unspecified numeric_limits from compiling.

An alternative to this suggestion would be to still define the primary template, but not provide any of the members except is_specialized. Either way, this would make numeric_limits members SFINAEable.

Along the same lines, one might wonder why the members that only make sense for floating-point types are required to be defined to nonsense values for integer types.

[2016-11-12, Issaquah]

Sat PM: This looks like a good idea. Jonathan and Marshall will do post C++17 implementations and report back.

[2018-11 San Diego Thursday night issue processing]

See Walter's paper P0437 for ideas and/or future directions.

[2023-04]

See Walter's paper P1841 for the preferred direction.

Proposed resolution: