On 2020-04-10 at 20:27, Thomas Mercier via Std-Proposals wrote:
> 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.
>

I believe the current wording is to support code like this

if (numeric_limits<T>::is_specialized)
    // use other members
else
    // alternate code


Before the invention of constexpr-if both paths of the if-statement just
had to contain valid code to compile. Thus valid dummy values (0/false)
for non-numeric T's.


     Bo Persson