C++ Logo

std-proposals

Advanced search

Re: Make non-specialized numeric_limits<T> use ill-formed

From: W Brown <webrown.cpp_at_[hidden]>
Date: Tue, 14 Apr 2020 10:19:33 -0500
FYI, those papers (P0437R1 and P1370R1) have since been consolidated and superseded by P1841R0 <http://wg21.link/p1841>. Moreover, ...

...even P1841R0 is now dated. I enclose D1841R1, an updated draft, tentatively planned for publication next month. Private (off-list) comments welcome.

Finally, please note that this and many similar small-ish proposals are not considered a priority by WG21. LWG (WG21's Library Working Group) has a considerable backlog of such papers to review, some in their queue for years. It is therefore not currently predictable when any of these proposals will be given final consideration/approval, especially under the current circumstances that have already led to one WG21 meeting's cancellation.

Stay safe, everyone. Best,

-- WEB




> On Apr 14, 2020, at 8:16 AM, Michael Hava via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Thanks! I wasn’t aware of P0437.
>
> From: John McFarlane <john_at_[hidden]>
> Sent: Tuesday, April 14, 2020 11:54 AM
> To: std-proposals_at_[hidden]
> Cc: Michael Hava <mfh_at_[hidden]>
> Subject: Re: [std-proposals] Make non-specialized numeric_limits<T> use ill-formed
>
> On Mon, 13 Apr 2020 at 15:33, Michael Hava via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
> 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.
>
> See P0437R1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0437r1.pdf> and P1370R1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1370r1.html> for work in this direction.
>
> 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,…)
>
> It should although numeric_limits does allow custom specialization.
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden] <mailto: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] <mailto:std-proposals_at_[hidden]>
> Cc: Thomas Mercier <thomas.mercier.jr_at_[hidden] <mailto: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 <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 <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 <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 <https://godbolt.org/z/YVSECn>

Received on 2020-04-14 10:22:34