Clean up our type_traits headers (again)
While putting together some of the trickery required for the revised reference elements, I got to take a look at our headers with type traits again and noticed a few things:
It's unfortunate that(This isn't really worth it, see !464 (closed))
dune/common/typetraits.hhand not in
dune/common/std/type_traits.hh. It's also not in
Dune::Std. Can we still move it?
- We have again duplicated a bunch of functionality, with
Dune::Std::to_true_type<T>and the corresponding
falseversions. Should we get rid of one of them?
(!393 (merged)) For 2.5, we added the type trait
Dune::Std::is_callablealong the lines of N4446, but C++17 did instead get
std::is_invocable_r(see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0604r0.html for the (slightly arcane, but understandable from the EWG point of view) reasoning). This is not just a rename, the committee also changed the syntax by replacing the encoding of the arguments, going from the function-call-like
is_callable<F(Args...),R>to a more traditional
is_invocable<F,Args...>. The website listed above gives a good reason for that change. So the question is: What do we do with our implementation? Do we deprecate it and replace it with a fallback implementation of
std::is_invocable? If we do that, do we also add
- I don't get
EnableIfInterOperable<T1,T2,U>. Apart from the naming inconsistency, it checks for a really weird thing:
is_convertible_v<T1,T2> or is_convertible_v<T2,T1>. With a quick grep, I could only find it in the iterator facades. And there, it will lead to a compiler error if only one of the two conversions is valid. I'm in favor of deprecating it.
is_indexablecan be simplified quite a bit with our improved compiler requirements. I'll take care of that.
(!466 (merged)) The combination of
stl_likesyntax is probably here to stay, even though it might be good to use
CamelCasefor our own utilities and
stl_likefor standard library backports.