> bool is actually #define bool _Bool. You have to include <stdbool.h> to get it. That's ugly enough not to want to use it.
Sure, which is why it got changed to a keyword in C23. I'll agree this should have happened earlier.
The return type of comparison operators is entirely irrelevant; you don't build APIs by reference to the return type of a comparison operator. It makes a difference to the reader whether your source code says "int" or "bool", that alone is all the reason anyone should need.
> That is inaccurate. It's POSIX that reserves this namespace.
You got me there. However, the question is, why would you add the _t? It serves no purpose. Typedefs have their own namespace anyway, you're not working around some possible collision by adding the _t.
That said I've already noted this is a commonly ignored aspect. I suppose it "feels" better/correct to some readers. I will happily agree this is the weakest point of my feedback either way, yet I still rather point it out and have people learn more details about this.
When folks talk about namespaces, structs, & typedefs in C, it's to call out that `struct X` and `typedef int X;` can both exist at the same time. In other words, nothing prevents one from doing a `typedef struct X { int f; } X;` or similar, using `X` as the name in both places.
It is true that it's more correct to say "struct names have their own namespace", though I think we can infer what's actually meant here fairly easily.
Sure, which is why it got changed to a keyword in C23. I'll agree this should have happened earlier.
The return type of comparison operators is entirely irrelevant; you don't build APIs by reference to the return type of a comparison operator. It makes a difference to the reader whether your source code says "int" or "bool", that alone is all the reason anyone should need.
> That is inaccurate. It's POSIX that reserves this namespace.
You got me there. However, the question is, why would you add the _t? It serves no purpose. Typedefs have their own namespace anyway, you're not working around some possible collision by adding the _t.
That said I've already noted this is a commonly ignored aspect. I suppose it "feels" better/correct to some readers. I will happily agree this is the weakest point of my feedback either way, yet I still rather point it out and have people learn more details about this.