New Swift features (__nullable and __nonnull

Http://www.mamicode.com/info-detail-923593.html

Recently in the reading of the teacher to write code often encountered two unfamiliar keywords, but when I knocked on my computer is not the time to knock out, later only to know that this is for swift and OC mixed when a new feature, it is very carefully studied.

In Swift, you can use! and? To indicate whether an object is optional or non-optional, such as view? and view!. There is no such distinction in objective-c, and view can indicate that the object is optional or non-optioanl.

This creates a problem: When Swift and objective-c are mixed, the Swift compiler does not know whether a Objective-c object is optional or non-optional, So in this case the compiler implicitly treats the Objective-c object as a non-optional.

To solve this problem, Apple introduced a new feature of Objective-c in Xcode 6.3: nullability annotations.

At the heart of this new feature are two different types of annotations:__nullable and __nonnull. We can literally guess that__nullable indicates that an object can be null or nil, while __nonnull means that the object should not be empty. When we do not follow this rule, the compiler gives a warning.

Let's take a look at the following example,

1 @interface testnullabilityclass () 2 @property (nonatomic, copy) Nsarray * items; 3-(ID) Itemwithname: (NSString * __nonnull) name; 4 @end 5 @implementation Testnullabilityclass 6 ... 7-(void) testnullability {8     [self itemwithname:nil];    Compiler warning: Null passed to a callee that requires a non-null argument 9}10-(ID) Itemwithname: (NSString * __nonnull) name {11     return nil;12}13 @end

But this is just a warning that the program can be compiled and run.

In fact, you can use __nullable and __nonnull in any place where you can use the Const keyword, but these two keywords are limited to using pointer types. In the declaration of the method, we can also use nullable and nonnull, which are not underlined, as follows:

1	- (nullable id)itemWithName:(NSString * nonnull)name

There are also two additional attributes added to the attribute declaration, so the items property in the previous example can be declared as follows:

1	@property (nonatomic, copy, nonnull) NSArray * items;

Of course, you can do this in the following way:

1	@property (nonatomic, copy) NSArray * __nonnull items;

It is recommended to use nonnull this way, so that the property declaration will look clearer.

However, for security reasons, Apple has also set several rules:

1. The nullability attribute of a type defined by a typedef is typically dependent on the context, even in audited regions, and cannot be assumed to be nonnull.

2. A complex pointer type (such as ID *) must be shown to specify whether it is nonnull or nullable. For example, specify a nonnull pointer to a nullable object that can use __nullable ID * __nonnull.

3. The nserror that we often use is usually assumed to be a nullable pointer to the nullable Nserror object.

Because nullability annotations is a new addition to Xcode 6.3, we need to consider the old code before. In fact, Apple has helped us deal with this compatibility problem and we can safely use them:

1. The old code will still work, even if you use nil for the Nonnull object.

2. The old code will give a warning under the new Swift compiler when it needs to be mixed with Swift.

3. Nonnull does not affect performance. In fact, we can still judge whether our object is nil at run time.

In fact, we can see the nonnull/nullable with our assertions and exceptions, and the problems that need to be addressed are the same: a violation of the Convention is a programmer's fault. In particular, the return value is something we can control, and if the return value is nonnull, then we should not return nil unless it is for backwards compatibility.

New Swift features (__nullable and __nonnull