[ 2023-04 ]

See Walter's paper P1841 for the preferred direction.

[ 2018-11 San Diego Thursday night issue processing ]

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

[ 2016-11-12, Issaquah ]

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

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.