I just ran into a compiler error involving __bind_back and some overloads
that were being disabled with _EnableIf. I noticed that the error message
was quite bad and did not mention the reason for the overload being
excluded. Specifically, the error looked like this:
candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>'
Instead, when using enable_if or enable_if_t, the compiler is clever and
can produce better diagnostics, like so:
candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>]
Basically, it tries to do a poor man's implementation of concepts, which
is already a lot better than simply complaining about substitution failure.
Hence, this commit uses enable_if_t instead of _EnableIf whenever
possible. That is both more straightforward than using the internal
helper, and also leads to better error messages in those cases.
I understand the motivation for _EnableIf's implementation was to improve
compile-time performance, however I believe striving to improve error
messages is even more important for our QOI, hence this patch. Furthermore,
it is unclear that _EnableIf actually improved compile-time performance
in any noticeable way (see discussion in the review for details).
(1) What do the respective error messages look like with GCC? MSVC? (I bet those compilers lack Clang's special cases.)
(2) Is it conceivable that we could just make Clang understand anything-of-the-general-form-of-_EnableIf, based on the class template's shape, instead of based on special-casing its name?
(3) If all else fails, could we keep using the spelling _EnableIf, and just define _EnableIf as an alias for enable_if_t? At least then it would be easy for anyone who cared about compile-time performance to just patch it in one place. (Arguably I bet it would do no harm for them to patch it at the enable_if_t level, and thus speed up even more things than just libc++ itself.) Also, it would make this patch a lot less invasive.
(4) Is this the camel's nose in the tent? Are you soon going to propose replacing _If with conditional_t? Do we want this?