38

Within a Swift class derived from an Obj-C based framework (but could just as easily be a Swift class with an @objc attribute) I declare two stored properties:

var optInt: Int?
var optString: String?

Only optString is being exposed to Obj-C via the generated -Swift.h header.

String? is presumably fine because it is exposed using an NSString object which can be nil, so the bridging has a way to represent no value.

If I remove the ? from optInt it's exposed with an NSInteger type, so I can see that for non-optional integers it avoids objects and bridges value type to value type, but does this literally mean that an Int? can't be exposed?

I can't seem to find any documentation that explicitly says this is the case. There is a whole list of incompatible Swift features here that this doesn't appear on: Using Swift from Objective-C

The use case here is the classic situation requiring the passing of a numeric ID which could legitimately be zero. In the pre-Swift world NSNumber and nil is exactly how I went about implementing this, but it just feels wrong to be trying to migrate a class to Swift but then hanging on to Obj-C types within the Swift class specifically for this reason.

I suppose I had envisaged that an Int? unlike Int would bridge as an NSNumber in the background, with its potentially nil value feeding the "has no value" element of the optional in Swift.

Is there anything I'm missing here? To reiterate, can a Swift Optional Int (Int?) be exposed to Objective-C via bridging?

Vladimir F Героям слава
  • 57,977
  • 4
  • 76
  • 119
Tom Hawley
  • 555
  • 1
  • 7
  • 12
  • 3
    I would try `NSNumber` with an `intValue` inside. – Sergey Kalinichenko Jun 14 '14 at 15:25
  • 1
    If the generated header isn't doing something with that property, then it would seem the answer is "no". Since Swift isn't finalized, though, file a bug with Apple if you think there's a sensible approach. (The problem with exposing it as `NSNumber*` is that you could store a non-`Int`-compatible `NSNumber` to it from Objective-C.) – Ken Thomases Jun 14 '14 at 16:07
  • 1
    You might make a computed `NSNumber?` property to wrap your `Int?` property. The getter would simply return the `Int?` variable. The setter would set the `Int` variable from `-[NSNumber integerValue]`. – Ken Thomases Jun 14 '14 at 18:26
  • I can see how that tightens up using `NSNumber?` and I guess it also paves the way to eventually remove the wrapper if/when Obj-C compatibility is no longer required, so i've adopted the idea. Thanks! – Tom Hawley Jun 14 '14 at 19:14
  • @KenThomases I think it would be nice if you can write your comment as an answer, since it solved OP's (and mine) problem. – nikolovski Oct 29 '14 at 12:15

2 Answers2

16

The problem with exposing an Int? property as NSNumber* is that you could store a non-Int-compatible NSNumber to it from Objective-C.

You can make a computed NSNumber? property to wrap your Int? property. The getter would simply return the Int? variable. The setter would set the Int variable from -[NSNumber integerValue].

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
15

Here's a concrete answer for the solution described above:

private var _number: Int?
public var number: NSNumber? {
    get {
        return _number as NSNumber?
    }
    set(newNumber) {
        _number = newNumber?.intValue
    }
}

// In case you want to set the number in the init
public init(number: NSNumber?) {
    _number = number?.intValue
}
Jen C
  • 460
  • 5
  • 14