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

[David Ayers]

Richard Frith-Macdonald wrote:
>

> I would also be happy if we could change BOOL to be the same as the 
> _Bool type Alexander mentioned (preferably with a compiler option to 
> warn about possibly bad assignments), but that would require 
> co-operation from Apple and gcc people of course.
>
> Do you think it's worth contacting someone from Apple?

I'm not sure this can happen easily as it might break a whole lot.  We'd 
have to look into how this would affect @encode & co. as I believe it 
currently doesn't differentiate between BOOL and char (but I'm not 
sure).  But I really don't think we need to go there.

The questions to me are:
- Is the typedef BOOL allowed to limit the valid values to YES and NO 
and are we entitled to enforce that.
- Is an int or any other scalar (or now that that I think about it more 
even a pointer) by itself a valid "condition"?

I'm not talking about a coding convention within GNUstep to avoid this, 
I'm asking whether we are entitled to require this of third party code 
(even if this third party code is writing categories on our classes).

I don't really think so, even if we consider it bad style.  This is why 
I really think we shouldn't compare with "== YES" but rather with "!= 
NO" (or "!= nil" or what ever is applicable.)  I'm fine with coding 
conventions that require some tests that can be considered redundant for 
readability.  I don't think that we're entitled to force these 
conventions on others (even when building with NDEBUG).

Cheers,
David