>>704
Given _Bool's semantics, I wouldn't agree. For example:

#include <stdio.h>

#define THING(T, S) {                        \
  T a = 1;                                   \
  T b = a + a;                               \
  T c = b - a;                               \
  T d = 1 + 1 - 1;                           \
  printf("1 + 1 - 1 considered as " S "\n"); \
  if (d) {                                   \
          printf(" != 0 all at once\n");     \
  } else {                                   \
          printf(" == 0 all at once\n");     \
  }                                          \
  if (c) {                                   \
          printf(" != 0 split\n");           \
  } else {                                   \
          printf(" == 0 split\n");           \
  }                                          \
}

int main(void)
{
        THING(int, "int");
        printf("\n");
        THING(_Bool, "_Bool");
        return 0;
}

That distinction is necessary specifically because if operates on integral types, and in order to preserve backwards compatibility, _Bool needed to be an integral type when it was introduced. I'm sure you know all that, but the point is that the semantics of if dictate _Bool, not the other way around, and this has caused the _Bool type to be very strange.

The above is a MWE of a very real bug caused by somebody who didn't understand this and incorrectly refactored some code from uint_fast8_t to bool without bothering to read it closely enough. Their justification was "if takes a boolean, so all variables in conditions should be booleans to prevent casting".