clang should interpret @(YES) the same as @YES

Originator:preble
Number:rdar://12761621 Date Originated:11/27/2012
Status:Duplicate Resolved:
Product:Developer Tools Product Version:Xcode 4.5.2
Classification:Enhancement Reproducible:Always
 
The clang compiler should interpret @(YES), or better @(boolean expression), as equivalent to @YES or @NO.  The former results in an __NSCFNumber, while the latter is an __NSCFBoolean. This creates subtle problems when using APIs such as GLKit's -textureWithContentsOfFile:options:error:, which appears to use == kCFBooleanTrue to compare values passed via its options dictionary (see bug 12761147).

Bug was closed as a duplicate of rdar://12156616. This bug was later fixed in Xcode 4.6, so now @(boolean expression) now results in kCFBooleanTrue or kCFBooleanFalse.

Comments

@NO!

Well @YES is a keyword and @(YES) is actually @(__objc_yes) or @((BOOL)1) as YES is #defined to __objc_yes or (BOOL)1. [Which have type signed char.]

How should @(boolean expression) distinguish boolean expression from from an integer expression?

I don’t think Obj-C can do this.

Why don’t you simply define: 

inline NSNumber* NSBool (BOOL f) { return (NSNumber*) (f ? kCFBooleanTrue : kCFBooleanFalse); }

Then you can write NSBool(<boolean-expression>) wherever you need it.

You could also define: 

inline NSNumber* NSTrue () { return (NSNumber*) kCFBooleanTrue; }

inline NSNumber* NSFalse () { return (NSNumber*) kCFBooleanFalse; }

for completeness.

By chris0 at Dec. 10, 2012, 8:28 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!