[libc++] Use enable_if_t instead of _EnableIf

Authored by ldionne on Aug 17 2021, 9:26 AM.


[libc++] Use enable_if_t instead of _EnableIf

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).

Differential Revision: https://reviews.llvm.org/D108216


ldionneSep 8 2021, 6:09 AM
Differential Revision
D108216: [libc++] Use enable_if_t instead of _EnableIf
rG1524b0154116: [MLIR] Add loop coalesce utility for affine.for