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.
Section: 17.3.5 [numeric.limits] Status: Open Submitter: Richard Smith Opened: 2016-06-09 Last modified: 2018-11-13
View other active issues in [numeric.limits].
View all other issues in [numeric.limits].
View all issues with Open status.
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 (220.127.116.11 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.
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.