search

dsharlet / array

C++ multidimensional arrays in the spirit of the STL
Apache License 2.0
198 stars 15 forks source link

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

Open dsharlet opened 4 years ago

dsharlet commented 4 years ago

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 commented 4 years ago

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

dsharlet commented 4 years ago

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 commented 1 year ago

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 commented 1 year ago

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.