You are trying to tell us that the advantage of making bool, false and
true a typedef enum rather than macros is that you can re-use the names
as local variables and struct members?
Note that this adds up as an argument against having reserved keywords.
Because _Bool is a keyword, its use as an identifier in any scope,
at any level of syntax is pervasively disallowed.
Since bool is a preprocessor alias for _Bool, it then appears as if bool is
also a keyword, even though preprocessor symbols lack lexical scoping.
You are prohibited from uses of bool that would also be prohibited if
bool were an actual keyword.
But re-using "bool", "false" or "true" as local variable names or struct
members is in no way "perfectly reasonable local use" - such code would
be cryptic and confusing, and would be highly unlikely to occur in even
the most badly written code.
If not being able to use "bool" or "false" as a local variable name
or struct member is a problem, then so is not being able to use "int" or
"extern" as a local variable name.
(That argument can be made. I'm not making it here, but my point is that the
argument should be properly generalized and shouldn't focus entirely on
So we are back to your original claim - either give us an example of
/perfectly reasonable/ use where macro bool would not work while typedef
bool would be valid, or accept that the macro versions work fine.
A typedef (or type specifier keyword) bool would be visible in debuggers as
"bool", and values of objects of that type would show up as "true" and "false".
(Of course, debuggers can support some hack whereby they provide an
altered presentation of _Bool and its domain values.)