Date: Mon, 13 Apr 2020 14:33:06 +0000
IMHO: The definition of numeric_limits is rather unfortunate (is_specialized, min vs lowest, countless members that have no meaning for certain types, …), but I seriously doubt that we can/should try to change it after 20+ years…
If anything can be done in this area, it should most probably be a new facility for these limits that follows a more modern (read: non-monolithic) design.
Note: type_traits already exposes some of the functionality of numeric_limits (is_signed, is_integral, …).
Best regards,
Michael
Food for thought: maybe a new limits-system should include support for “custom arithmetic types” (e.g. complex,…)
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Thomas Mercier via Std-Proposals
Sent: Friday, April 10, 2020 8:27 PM
To: std-proposals_at_[hidden]
Cc: Thomas Mercier <thomas.mercier.jr_at_[hidden]>
Subject: [std-proposals] Make non-specialized numeric_limits<T> use ill-formed
Hi,
I encountered some surprising behavior from the std::numeric_limits<T> class template when experimenting with std::byte. The integer representation of the maximum std::byte value is 0 according to std::numeric_limits<std::byte>::max(). That is because there is no specialization of std::numeric_limits<T> for std::byte, because std::byte is not an arithmetic type. Ok, fine. But the fact that the program compiles, and produces an unexpected value is worrisome!
The standard specifies that "The default numeric_limits<T> template shall have all members, but with 0 or false values." (https://eel.is/c++draft/numeric.limits#3)
I would prefer to see this say something like, "a program which uses the default numeric_limits<T> template is ill-formed", so that an error is produced at compile time rather than a value initialized result (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/limits#L321 and https://github.com/llvm/llvm-project/blob/master/libcxx/include/limits#L150).
Does anyone know why the current wording specifies "0 or false values", or what any objections to my suggested change might be?
https://godbolt.org/z/YVSECn
Thanks,
T.J.
If anything can be done in this area, it should most probably be a new facility for these limits that follows a more modern (read: non-monolithic) design.
Note: type_traits already exposes some of the functionality of numeric_limits (is_signed, is_integral, …).
Best regards,
Michael
Food for thought: maybe a new limits-system should include support for “custom arithmetic types” (e.g. complex,…)
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Thomas Mercier via Std-Proposals
Sent: Friday, April 10, 2020 8:27 PM
To: std-proposals_at_[hidden]
Cc: Thomas Mercier <thomas.mercier.jr_at_[hidden]>
Subject: [std-proposals] Make non-specialized numeric_limits<T> use ill-formed
Hi,
I encountered some surprising behavior from the std::numeric_limits<T> class template when experimenting with std::byte. The integer representation of the maximum std::byte value is 0 according to std::numeric_limits<std::byte>::max(). That is because there is no specialization of std::numeric_limits<T> for std::byte, because std::byte is not an arithmetic type. Ok, fine. But the fact that the program compiles, and produces an unexpected value is worrisome!
The standard specifies that "The default numeric_limits<T> template shall have all members, but with 0 or false values." (https://eel.is/c++draft/numeric.limits#3)
I would prefer to see this say something like, "a program which uses the default numeric_limits<T> template is ill-formed", so that an error is produced at compile time rather than a value initialized result (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/limits#L321 and https://github.com/llvm/llvm-project/blob/master/libcxx/include/limits#L150).
Does anyone know why the current wording specifies "0 or false values", or what any objections to my suggested change might be?
https://godbolt.org/z/YVSECn
Thanks,
T.J.
Received on 2020-04-13 09:36:04