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 was something unexpected,
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.
Alt
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.
Cheer
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
>
> 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: method is actually
> 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.
NSObject.h (from which Sean was quoting) begins
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 nullability is *unspecified*,
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 list.
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 Jan 13, 2017, at 9:46
> 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 the receiver. May be nil,
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) _updateFr
11 matches
Mail list logo