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

[Richard Frith-Macdonald]

On 2 Feb 2004, at 12:08, David Ayers wrote:

> 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.

For sure it would require compiler changes ... if it was trivial, I 
suspect the change would have been made long ago.

> 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.

Within our own code we can enforce it, where we interface to other code 
we have to accept what the compiler
allows people to do ... but that doesn't mean we can't warn about it.  
In the vast majority of cases people only
use the correct values, occasionally, they don't ... and sometimes this 
is fine, other times it's indicative of a bug
in their code.

> - Is an int or any other scalar (or now that that I think about it 
> more even a pointer) by itself a valid "condition"?

Well, of course it in both C and ObjC ... technically.  However, I 
think it makes much clearer/readable/maintainable
code  where you either have a logical operator or a function/method 
name which is clearly that of a predicate.

> 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).

That's why one of my suggestions was a warning ... I expected an 
exception to be judged to be too strong.
My gut instinct is that people writing methods which return non-YES/NO 
values in a BOOL is so rare that
raising an exception would likely not be a big issue ... but that might 
not be the case ... certainly a warning
is safer.