Comment by David Owens (JIRA)

After digging a bit more, I think this is OK. We can use the CFBoolean type and get by.

Comment by David Owens (JIRA)

Re-opening. I've found another wrinkle.

let b: AnyObject = true

This gets bridged to an NSNumber type. When you have the ObjC runtime, it gets the __NSCFBoolean type.

So there is no way that I can see to get back from a Swift bool value for serialization/deserialization when AnyObject is in the interface.

FWIW, the way the ObjC Foundation and CoreFoundation work is that creating an NSNumber/CFNumber with a boolean doesn't just give you __NSCFBoolean, it actually explicitly gives you one of the two global constants kCFBooleanTrue or kCFBooleanFalse, and you're supposed to detect that it's a boolean by doing pointer equality against those two constants (since the type __NSCFBoolean is private).

If (when?) we get proper factory method support from Swift, we should be able to return the private singleton subclasses directly.

See also [SR-457] for a workaround but proper factory method support will make fixing this a lot cleaner

Comment by Jens Alfke (JIRA)

There needs to be a way to get the exact type of the stored number. The boolean case described above is just one example, but there are others:

• When formatting a floating-point number, you should use 6 decimal places if it's a float, 16 if it's a double. (If you use all 15 for a float, you end up with results like “0.999999999999999” instead of “0.1”.)

• When getting the integer value of an NSNumber, most of the time you can use longLongValue. But if the internal number is an unsigned 64-bit int you have to use unsignedLongLongValue (and assign it to a UInt64), otherwise it may overflow and appear negative.

In Apple Foundation the `objcType` property lets you do this (except with booleans, which return the wrong type code `c`). But that's obviously a bad name to use in a Swift API…