Re: Seeing nil passed to isEqual:, despite non-null declaration

On Jan 13, 2017, at 10:59 , Sean McBride wrote: > > I'd say the header is in error in the sense that it should have nullability > specified. You may be right, but my post was an *informal* comment in the sense that you seemed to be asking whether a nil parameter value

Re: Seeing nil passed to isEqual:, despite non-null declaration

Hi Sean Yes, I was bitten by that too, very, very recently, when I was translating a few files into Swift and I got warning when I didn’t use an optional for the object of the method. Actually, I suspect that’s a bug in the headers, or probably that’s a non-audited header for nullability.

Re: Seeing nil passed to isEqual:, despite non-null declaration

On Fri, 13 Jan 2017 10:51:18 -0800, Jens Alfke said: >So Quincey is actually correct — isEqual: has unspecified nullability, >and the header is not in error. I'd say the header is in error in the sense that it should have nullability specified. Quite surprising that it's not done by now.

Re: Seeing nil passed to isEqual:, despite non-null declaration

On Fri, 13 Jan 2017 10:43:09 -0800, Ben Kennedy said: >> Did I miss a change in clang that made the default “not nullable”?? I >read the above declaration as meaning that the nullability is >*unspecified*, which implies that nil is allowed. > >NSObject.h (from which Sean was quoting) begins with

Re: Seeing nil passed to isEqual:, despite non-null declaration

> On Jan 13, 2017, at 10:43 AM, Ben Kennedy wrote: > > NSObject.h (from which Sean was quoting) begins with NS_ASSUME_NONNULL_BEGIN > which, to my understanding, makes everything in the file be non-nullable > unless otherwise annotated. You’re looking at . But the -isEqual:

Re: Seeing nil passed to isEqual:, despite non-null declaration

> On 13 Jan 2017, at 10:34 am, Quincey Morris > wrote: > > Did I miss a change in clang that made the default “not nullable”?? I read > the above declaration as meaning that the nullability is *unspecified*, which > implies that nil is allowed.

Re: Seeing nil passed to isEqual:, despite non-null declaration

On Jan 13, 2017, at 09:46 , Sean McBride wrote: > > NSObject.h declares: > > - (BOOL)isEqual:(id)object; > > Note the parameter is not nullable. Did I miss a change in clang that made the default “not nullable”?? I read the above declaration as meaning that the

Re: Seeing nil passed to isEqual:, despite non-null declaration

On Fri, 13 Jan 2017 09:53:25 -0800, Jens Alfke said: >So yes, the parameter should be declared as `nullable`. Thanks, Sean ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the

Re: Seeing nil passed to isEqual:, despite non-null declaration

I was thinking, and I'm guessing there were no warnings and errors in Xcode on this line of code, that a clean compile would indicate that the header did not match the documentation. Does this make sense? Sandor > On Jan 13, 2017, at 12:53, Jens Alfke wrote: > > >> On

Re: Seeing nil passed to isEqual:, despite non-null declaration

> On Jan 13, 2017, at 9:46 AM, Sean McBride wrote: > > Anyone ever seen nil passed to isEqual:? Is the SDK declaration maybe wrong? Check the class documentation, not just the header. The parameter is declared as: anObjectThe object to be compared to

Seeing nil passed to isEqual:, despite non-null declaration

Hi all, NSObject.h declares: - (BOOL)isEqual:(id)object; Note the parameter is not nullable. And yet, I'm seeing nil passed to one of my class's overrides of isEqual: when I invoke Edit>Undo. Backtrace: #4 -[RRLookupTable isEqual:] #5 -[NSManagedObject(_NSInternalMethods)