Re: Seeing nil passed to isEqual:, despite non-null declaration
Re: Seeing nil passed to isEqual:, despite non-null declaration
- Subject: Re: Seeing nil passed to isEqual:, despite non-null declaration
- From: Quincey Morris <email@hidden>
- Date: Fri, 13 Jan 2017 13:50:03 -0800
- Feedback-id: 167118m:167118agrif8a:167118s1GNnEpG6_:SMTPCORP
On Jan 13, 2017, at 10:59 , Sean McBride <email@hidden> 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, and I was trying to say that, historically, no, I’m not aware of the need to make any particular assumption.
The second part of my post was intended to point out that any attempt to formalize this is going to be difficult due to existing code. If you read the clang document, things start to get tricky, because the annotations impinge on at least these aspects:
— The expectations of the caller about what may be passed.
— The expectations of the implementer about how to handle values that are passed.
— The difference between error detection and undefined behavior.
— The difference between a parameter annotation and a pointer annotation (which I wasn’t aware of until I read that document today).
— The semantics of the call, separate from syntactic clues. (For example, according to the documentation, it would be a semantic violation for the method to ever return YES if the parameter was nil. That’s a separate issue from whether the parameter can be nil.)
So, for all these reasons, I would assume the correct annotation would be “_Null_unspecified”, which is clang’s way of just shrugging, and I would assume the lack of explicit annotation would default to this.
I probably should have just omitted the second part of my post, since I didn’t realize that there was some question about the assumed nullability macros in different versions of the header, or how the method translates into Swift (which is the source of all the nullability fuss to begin with).
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden