Date: Tue, 14 Apr 2020 10:02:18 -0400
Sorry - that may come across wrong - I'm not trying to bait anyone. I have seen code that provides specializations of numeric_limits, and you assert quite freely that such action is allowed by the standard. However, I have never seen any formal justification that the standard actually allows it. Thus, I would be very interested to see support for such a stance.
I will quote, C++17 and C++20, but the language in previous standards is similar - though C++20 has extra language to make attempts to provide more restrictions on touch stuff in std.
C++17 - 20.5.4.2.1/1 [namespace.std]
The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.
C++20 - 16.5.4.2.1/2 [namespace.std]
Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace std provided that (a) the added declaration depends on at least one program-defined type and (b) the specialization meets the standard library requirements for the original template.
Note, in particular, the second condition in both - that the specialization meets the standard library requirements of the original template.
Now, let's look at numeric_limits to determine the requirements of the original template.
C++17 - 21.3.4/1 [numeric.limits]
The numeric_limits class template provides a C++ program with information about various properties of the implementation’s representation of the arithmetic types.
C++20 - 17.3.5/1 [numeric.limits]
The numeric_limits class template provides a C++ program with information about various properties of the implementation’s representation of the arithmetic types.
The requirements of the original template apply only to the implementation's representation of the arithmetic types. Since it is impossible for any user-defined type to satisfy this constraint, it is impossible for any user defined type to provide a specialization that meets the standard library requirements for the original template. Thus, according to the standard itself, the behavior of a program is undefined if it adds a template specialization for std::numeric_limits.
Don't get me wrong - I would love to see where the standard allows such specialization. I'm even somewhat OK with implication, but here there seems to be explicit contradiction to such specializations.
> On Apr 14, 2020, at 8:15 AM, Jody Hagins <coachhagins_at_[hidden]> wrote:
>
> Hi John.
>
> Please provide support from the standard for your last sentence: "It should although numeric_limits does allow custom specialization."
>
>
>
>
>> On Apr 14, 2020, at 5:54 AM, John McFarlane via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>>
>> 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.
>>
>> Cheers,
>> John
>>
>>
>>
>> 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>
>>
>> Thanks,
>> T.J.
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
I will quote, C++17 and C++20, but the language in previous standards is similar - though C++20 has extra language to make attempts to provide more restrictions on touch stuff in std.
C++17 - 20.5.4.2.1/1 [namespace.std]
The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.
C++20 - 16.5.4.2.1/2 [namespace.std]
Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace std provided that (a) the added declaration depends on at least one program-defined type and (b) the specialization meets the standard library requirements for the original template.
Note, in particular, the second condition in both - that the specialization meets the standard library requirements of the original template.
Now, let's look at numeric_limits to determine the requirements of the original template.
C++17 - 21.3.4/1 [numeric.limits]
The numeric_limits class template provides a C++ program with information about various properties of the implementation’s representation of the arithmetic types.
C++20 - 17.3.5/1 [numeric.limits]
The numeric_limits class template provides a C++ program with information about various properties of the implementation’s representation of the arithmetic types.
The requirements of the original template apply only to the implementation's representation of the arithmetic types. Since it is impossible for any user-defined type to satisfy this constraint, it is impossible for any user defined type to provide a specialization that meets the standard library requirements for the original template. Thus, according to the standard itself, the behavior of a program is undefined if it adds a template specialization for std::numeric_limits.
Don't get me wrong - I would love to see where the standard allows such specialization. I'm even somewhat OK with implication, but here there seems to be explicit contradiction to such specializations.
> On Apr 14, 2020, at 8:15 AM, Jody Hagins <coachhagins_at_[hidden]> wrote:
>
> Hi John.
>
> Please provide support from the standard for your last sentence: "It should although numeric_limits does allow custom specialization."
>
>
>
>
>> On Apr 14, 2020, at 5:54 AM, John McFarlane via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>>
>> 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.
>>
>> Cheers,
>> John
>>
>>
>>
>> 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>
>>
>> Thanks,
>> T.J.
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
Received on 2020-04-14 09:05:20