On Aug 18, 2012, at 20:48 , Jens Alfke < email@hidden> wrote: *blink* I didn't even know there were @YES and @NO, although it makes sense that there would be. I'll give them a try. (I wish we could get away from the ancient legacy BOOL/YES/NO stuff, since C's had native booleans for 12 years now, but I digress.)
In that case, the encoding of @true and @false is even weirder, because based on their names, they ought to be "b", the C99/C++ "bool" type.
As Roland says, the clang spec doesn't clearly define @true and @false for Obj-C, only for Obj-C++. I believe Roland is correct, therefore, that in in Obj-C, they're treated like @1 and @0 (due to compile time conversion), rather than @YES and @NO.
The clang document does say this:
The compiler implicitly converts __objc_yes and __objc_no to (BOOL)1 and (BOOL)0. The keywords are used to disambiguate BOOL and integer literals.
which means that the compiler knows to use 'numberWithBool:' to create @YES and @NO.
However, this doesn't actually get you what you want. The encoding type of a NSNumber is an implementation detail:
There's no API contract violation in even @YES/@NO yielding a NSNumber with an objCType of 'i'. CFNumber documents a similar limitation (and doesn't seem to have a type unique to C++ 'bool', also suggesting that the encoding types returned by NSNumber might actually be synthesized from CFNumber type codes, rather than being stored directly).
That means that perhaps your bug should have perhaps been filed against NSNumber or NSJSONSerialization. It's a subtly difficult issue, though. NSNumber really only provides the abstract (numerical) values of numbers, not their representation. You'd have the same problem if JSON distinguished between "1" and "1.0" -- there's no guarantee that 'numberWithInteger:1' and 'numberWithDouble:1.0' will have distinct internal representations.
I don't see any satisfactory way out without adding an "intendedRepresentation" property to NSNumber/CFNumber.
|