Well, I found -Wbool-conversion, but it didn't seem to warn me when I did:
if (self.active)
where self.active is an NSNumber* property (the correct code in this case was 'self.active.boolValue').
In my ideal world, bool would be a first-class citizen, and it would be an error to put a non-bool _expression_ in there (there'd be no implicit type conversion to bool).
Yet I'm not sure that you've thought this through entirely. In order for 'if (self.active)' to escape your projected warning, it would have to be referring to a property of type 'bool'. That would mean, not only that it couldn't be a property of type NSNumber*, but it also couldn't be a property of type 'int'. This means that, to write a syntactically immaculate test, you'd need to know in advance what the type of property this is, out of a range of plausible guesses. If you know what it is, you're unlikely to write 'self.active' when you mean 'self.active.boolValue'. Much the same thing can be said, BTW, if you use an explicit boolean operator: 'self.active != <what?>'. You need to know the property type to decide whether to code the RHS as 'nil', '0' or 'false'.
IOW, compile-time checks don't help a great deal. There's no actual substitute for knowing the API.
The issue you raise shows up fairly often here or on cocoa-dev. Cf: today's thread about whether '0' is "better" than a symbolic constant, or a recent thread where Jens (unintentionally) hilariously complained that if he (accidentally) forgot to provide the implementation of a custom property, his app didn't work. (Apps usually don't work if you leave out the code. We feel his pain.)
FWIW
|