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 <j...@mooseyard.com> wrote: > > >> On Feb 25, 2016, at 4:02 PM, dangerwillrobinsondan...@gmail.com 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
_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
