> On Aug 8, 2015, at 1:15 PM, Seth Willits <sli...@araelium.com> wrote: > > Let's stipulate that _Nullable and _Nonnull are great to have because they > can catch bugs and express API intent better than before, so we want them. > The question is where to put them? > > > _Nullable and _Nonnull make perfect sense to specify in the @interface. Since > those annotations existing in the @interface will produce applicable warnings > and errors in the counterpart @implementation,there's really no _need_ to > respecify them in the @implementation of those same methods. > > It makes sense for private methods to have nullability annotations for all > the same reasons public Now let's assume that private methods aren't > specified in any @interface, even the anonymous one. In that case, those > methods would naturally have no annotations on their parameters or return > values unless they're specified within the @implementation. But specifying > them on the private methods in the @implementation while *not* specifying > them for the public methods in the @implementation is inconsistent and > potentially confusing. > > > So I see two choices here: > > 1) Always add nullability annotations, for all methods and properties in both > the @interface and @implementation. (Private methods may or may not be > declared within @interfaces — but these days I think it's generally not done?) > > 2) Only add nullability annotations in the @interface, and always declare > private methods within an @interface. > > Is there a third choice I'm not thinking of? > > Thoughts? I'm curious how Apple is adopting these annotations themselves.
This is my personal opinion, but I would probably annotate everything given time and ability. From my experience, and as others have mentioned it definitely can catch bugs, and will help clarify your thoughts. However, given the verbosity of the syntax compared to Swift, it can be hard to get this done in a large code base. Also something to consider is that you can’t really add it piecemeal – if you add one notation, the compiler will generate warnings for all other declarations, which can cause a lot of warnings. So I would be pragmatic about it at this time. But if it is code you plan to port to Swift (as opposed to rewriting it entirely, but maybe even then) having the information there for you now can be very useful. > > > > -- > Seth Willits > > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
