That's a spanking good example. I have run into that myself. Unfortunately it's victim to the Swift Nullability universe. It is impedance mismatch. And why the warnings are off in Objective-C I suppose. The count check is a classic guard that tells us it's ok to access objects in that range.
Arguable the analyzer should know this. Sounds like a tools bug then. :)
Sent from my iPhone
On Feb 26, 2016, at 9:14 AM, Jens Alfke < email@hidden> wrote:
With Nullability in this case, you should create a reference and check if it is nil before passing it to a method that expects nonnull. It's an extra little bit of code but it does exactly what this warning expects and is for. It's really the right thing to do based on what the API expects.
Often, yes. But there are a number of cases where you already know by other means that the value is non-null, for example if (a.count >= 3) [widgets addObject: a.firstObject] Testing a.firstObject for nil would be pointless.
This is the equivalent of those times when you use “!” to dereference an optional in Swift.
—Jens
|