Date: Tue, 14 Apr 2020 12:32:41 -0400
> On Apr 14, 2020, at 11:26 AM, John McFarlane <john_at_[hidden]> wrote:
>
>
> 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.
>
> I don't think that counts as a requirement, more a statement about what numeric_limits does out of the box.
>
I wish that were true. However, that statement is not in the part that describes the specializations, but the class template itself - along with all the other requirements of the class template. This is even more clear when reading it in context as it is paragraph #1 - right before the description the primary template.
> On Apr 14, 2020, at 11:26 AM, John McFarlane <john_at_[hidden]> wrote:
>
> On Tue, 14 Apr 2020 at 15:03, Jody Hagins via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
> 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.
>
> I don't think that counts as a requirement, more a statement about what numeric_limits does out of the box.
>
> 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] <mailto: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>
>
> --
> 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>
>
>
> 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.
>
> I don't think that counts as a requirement, more a statement about what numeric_limits does out of the box.
>
I wish that were true. However, that statement is not in the part that describes the specializations, but the class template itself - along with all the other requirements of the class template. This is even more clear when reading it in context as it is paragraph #1 - right before the description the primary template.
> On Apr 14, 2020, at 11:26 AM, John McFarlane <john_at_[hidden]> wrote:
>
> On Tue, 14 Apr 2020 at 15:03, Jody Hagins via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
> 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.
>
> I don't think that counts as a requirement, more a statement about what numeric_limits does out of the box.
>
> 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] <mailto: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>
>
> --
> 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 11:35:41