Reasons not to use _Bool in Objective-C?

Question

Since C99, C now has a proper Boolean type, _Bool. Objective-C, as a strict superset of C, inherits this, but when it was created back in the 1980s, there was no C Boolean type, so Objective-C defined BOOL as signed char.

All of Cocoa uses BOOL, as does all non-NeXT/Apple Cocoa code that I've seen. Obviously, for compatibility with existing protocols (e.g., -applicationShouldTerminateAfterLastWindowClosed: from NSApplicationDelegate), matching the already-declared type is preferable, if for no other reason than to avert a warning.

For cleanliness/readability purposes, stdbool.h defines bool as a synonym for _Bool, so those of us who don't want unnecessary underscores in our code can use that.

Three other useful notes:

• @encode(_Bool) evaluates to "B". (@encode(BOOL) evaluates to "c", for signed char.)
• sizeof(_Bool) evaluates to 1, which follows from C99's definition that _Bool is only as large as necessary to hold its two possible values. (Edit: Actually, the standard says only that it must be “large enough” to hold those two values; it does not place an upper bound, and, in fact, Mac OS X on 32-bit PowerPC defines it as 4 bytes. Size difference is another thing to file under possible BOOL-vs.-bool compatibility issues.)
• On that note, the only two possible values of a _Bool are 1 and 0. Any other values are converted to one of these on assignment, as if you had done a double-negation (!!) or tested inequality against 0 (!= 0). The only ways to get a _Bool with some other value are the usual magicks: Pointer aliasing and unions.

Is there any reason not to use _Bool/bool in new code?

Answer 1

I think you all but answered your own question- the reason not to use _Bool in new Cocoa code is that, until Apple changes its frameworks over to using _Bool (or more probably, the bool defined in stdbool.h), you're breaking convention and possibly compatibility (at least without hacks) by using _Bool or bool. Although I've only been steeping in Cocoa programming for a couple years now, I'd bet that if Apple incorporates _Bool at all, they will probably simply redefine the BOOL macro to use the new type behind the scenes anyway, to avoid untold editing to their framework and its documentation.

That being said, (and let me preface this by disclaiming that I've yet to mix C code in with Objective-C and don't know the conventions for doing so), you have a much better case for using the new _Bool within C functions, probably with the caveat that it is only used internally and doesn't ask an Objective-C method to pass in a _Bool, just to avoid confusion for future programmers. You'd also of course have to be comfortable with always requiring C99 compilation, which people may still have reason to avoid. Considering YES is a macro for 1 and NO is a macro for 0, there doesn't seem to be much gain in requiring a newer version of C to get another char-sized value that only uses 1 or 0.

Honestly, when it comes down to it, you can get around any of these reasons with enough hackery or restrictions placed on reusability, but the end justification is that it's not (currently) part of the Cocoa/Objective-C slang, and its benefits probably won't outweigh the loss in readability and/or added confusion of other less-privy-to-_Bool programmers reading your code.