On Tue, 14 Apr 2020 at 15:03, Jody Hagins via Std-Proposals <
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]> 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]> wrote:
>
> On Mon, 13 Apr 2020 at 15:33, Michael Hava via Std-Proposals <
> 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]> *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.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>