[listeria]

Consider dropping the specializations for the type traits, given that it's undefined behavior:

https://en.cppreference.com/w/cpp/types/is_fundamental

https://en.cppreference.com/w/cpp/types/is_floating_point

https://en.cppreference.com/w/cpp/types/is_arithmetic

https://en.cppreference.com/w/cpp/types/is_scalar

https://en.cppreference.com/w/cpp/types/is_object

[dataflow]

Why is std::is_object even specialized here? Isn't it always true regardless?

[seg_fault]

I don't get what you mean. I thought they specify how the type can be used?

[badmintonbaseba]

The cppreference page says:

> If the program adds specializations for std::is_fundamental or std::is_fundamental_v, the behavior is undefined.

This is an oversimplification. The actual rule is https://eel.is/c++draft/library#namespace.std-2 .

> the specialization meets the standard library requirements for the original template.

For is_fundamental<YourClassType> it means that is_fundamental<YourClassType>::value must be false, as YourClassType is not a fundamental type, as defined in https://eel.is/c++draft/basic.fundamental#17 .

Some traits are just not designed to be customization points.

[secondcoming]

Technically, you're not supposed to add your own specialisations to the `std` namespace

[pmalynin]

In general this isn’t true (i guess it is in this specific context). For example I believe it’s totally expected to specialize std hash

[tyleo]

I’ve also done this with hash… though given the footguns scattered about, I wouldn’t be surprised if it broke the spec.

[Conscat]

That is a completely intended way to use std::hash, along with a few other functions like std::tuple_size and std::tuple_element.