Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?)

[Nicola Pero]

> > > Basically, you're claiming that BOOL may only take the values YES and
> > > NO, and that anything else is incorrect.
> > 
> > The Objective-C manual of NeXTstep 3.3 clearly states -
> > 
> > [snip
> > BOOL A boolean value, either YES or NO"
> > 
> > This precise definition
> [snip]
> 
> This isn't anywhere close to being a precise definition!

To me, it's clear enough what it means.  It means a BOOL is meant to be
either YES or NO. :-)

Yes, technically if you look at the actual header files, you can figure
out that you can assign other values to it, because it's a byte rather
than a bit - but like Richard and many others, I believe this is simply a
consequence of the fact that there was no way of defining a type
consisting of a single bit in C.  So they took the smallest they could get
away with, a byte.  But what they wanted was a boolean type, either YES or
NO, there is no doubt in the explanation.

Anyway to come to the point, while I see a good reason to say in our
coding standards that good code should try to work with non-{NO,YES}
values of BOOL for compatibility with C, I don't see any sound reason to
contradict the NeXTstep/Apple Objective-C Language Reference and actually
encourage or formalize as good such a use.

I'd propose the following -

"A BOOL should take either the value NO or the value YES; different
values should not occur in well written Objective-C code.

But to be easily compatible with code not following these standards
and which might mix BOOLs and C truth values (where zero is false and
anything non-zero is true), it's better to avoid comparing BOOL values
directly to YES; it's safer to compare them to NO."