Rationale for non-specialized numeric_limit's members' return values

[Sam]

This always looked to be the intuitive way to specialize for numeric types
only:

std::enable_if_t<std::numeric_limits<T>::is_specialized>

However, this becomes ill-formed if T is an array type, like T=char [4]
because of the default values of the non-specialized template, as specified
in [numeric_limits]:

static constexpr T infinity() noexcept { return T(); }
static constexpr T quiet_NaN() noexcept { return T(); }
static constexpr T signaling_NaN() noexcept { return T(); }
static constexpr T denorm_min() noexcept { return T(); }

I think this is a defect. The non-specialized template should either not
declare these at all, or declare but not define them.

[Bonita Montero]

Sorry, but who needs numeric_limits<*> for arrays ?

[Sam]

Bonita Montero writes:

> Sorry, but who needs numeric_limits<*> for arrays ?

Nobody. That's the whole point. That's exactly what I meant when I wrote "to
specialize for numeric types only".

[Öö Tiib]

Raw arrays are and remain nuisance forever.
Decay the possibly array to pointer, since also char* is not numeric type
but can be returned.

#include <type_traits>
#include <iostream>

using evil = char[4]; // <- your possibly array

int main()
{
// compiles and runs:
std::cout << std::numeric_limits<std::decay_t<evil>>::is_specialized
<< '\n';
}