refactor: specializations of standard templates may lead to UB

[JohelEGP]

One of the provisions of https://eel.is/c++draft/namespace.std#2 is

that (a) the added declaration depends on at least one program-defined type

A template specialization of the form

template<concept_name T> struct std::something<T>;

arguably does not depend on a program-defined type; its instantiations do. This library has plenty of that form.

Another potential issue is the increase in compile times with the proliferation of this form of specialization. This is similar to the benefits of using hidden friends. When a specialization depends on a program-defined type, the compiler skips all concept-constrained specializations (IIUC, see https://godbolt.org/z/E5Yv3vYP4).

Note that changing the specializations to use quantity<...> rather than Quantity might affect users who derive from quantity<...>.

[mpusz]

This library has plenty of that form.

Are there any other such specializations than std::common_type?

[JohelEGP]

Not that I can remember. I exaggerated a bit. The few I know are together and for the same primary template.

[JohelEGP]

When a specialization depends on a program-defined type, the compiler skips all concept-constrained specializations

I was wrong. You can see at https://godbolt.org/z/GeqhMoEo5 that checking whether a partial specialization is viable causes the instantiation of the class' body (and possibly more, depending on what the partial specialization checks).

It seems that reachable, constrained partial specializations can have unintended effects. I personally found this out when adding one for test types to cover a wide range of unit tests. A previous test on a trait that accepts incomplete types, for std::complex<void>, was now instantiating it and resulting in hard errors.