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: 2018-11-12

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_t`s
> - 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 `0`s and `false` values (18.3.2.4 of N4582), and instead `static_assert`ed, 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.

Proposed resolution: