shape allows construction from incompatible shapes (std::is_constructible and std::is_assignable are broken for std::tuple on various STLs)

[dsharlet]

Some compilers have a broken implementation of std::is_constructible<std::tuple<...>, std::tuple<...>>, which makes it hard to prevent shapes from being constructed/assigned from incompatible shapes.

[dsharlet]

std::is_assignable is broken in a different way on a different C++ STL...

[dsharlet]

I think this is not actually technically broken on the various STLs I've tried, it just fails in a way that doesn't produce the right SFINAE behavior. It produces large ugly stacks of compiler errors from inside std::is_constructible, instead of producing a false value.

[jiawen]

This issue is kinda important. Is it still a problem with STLs in use in 2023? To retain backwards compatibility, do we want to consider:

1. Implementing our own internal::is_constructible.
2. Adding an #ifdef to use std::is_constructible for users whose toolchains are not broken.
3. Reporting the bug and having it fixed upstream.

[dsharlet]

I tried re-enabling the usage of this here: https://github.com/dsharlet/array/tree/is_constructible. It seems to work fine, but actually relying on it to catch failures produces garbagy results for me still. You can try uncommenting this test and seeing what happens: https://github.com/dsharlet/array/blob/master/test/errors.cpp#L57-L61

I've found another problem here: the errors.cpp test is currently not passing on gcc, but it "passes" because -ferror-limit=0 is an unrecognized command line option on gcc, so it doesn't compile anything and the grep statement doesn't have a problem with it.