Sự khác biệt giữa nullable, __nullable và _Nullable trong Objective-C

Với Xcode 6.3, đã có các chú thích mới được giới thiệu để thể hiện rõ hơn ý định của API trong Objective-C (và để đảm bảo tất nhiên hỗ trợ Swift tốt hơn). Những chú thích đó là tất nhiên nonnull, nullablevà null_unspecified.

Nhưng với Xcode 7, có rất nhiều cảnh báo xuất hiện như:

Con trỏ bị thiếu một công cụ xác định loại nullable (_Nonnull, _Nullable hoặc _Null_unspecified).

Ngoài ra, Apple sử dụng một loại công cụ xác định vô hiệu hóa khác, đánh dấu mã C ( nguồn ) của họ:

CFArrayRef __nonnull CFArrayCreate(
CFAllocatorRef __nullable allocator, const void * __nonnull * __nullable values, CFIndex numValues, const CFArrayCallBacks * __nullable callBacks);

Vì vậy, để tổng hợp, chúng tôi hiện có 3 chú thích vô hiệu khác nhau này:

• nonnull, nullable,null_unspecified
• _Nonnull, _Nullable,_Null_unspecified
• __nonnull, __nullable,__null_unspecified

Mặc dù tôi biết tại sao và sử dụng chú thích nào, tôi hơi bối rối không biết nên sử dụng loại chú thích nào, ở đâu và tại sao. Đây là những gì tôi có thể thu thập:

• Đối với tài sản tôi nên sử dụng nonnull, nullable, null_unspecified.
• Đối với các thông số phương pháp tôi nên sử dụng nonnull, nullable, null_unspecified.
• Đối với phương pháp C tôi nên sử dụng __nonnull, __nullable, __null_unspecified.
• Đối với các trường hợp khác, chẳng hạn như con trỏ double tôi nên sử dụng _Nonnull, _Nullable, _Null_unspecified.

Nhưng tôi vẫn bối rối không biết tại sao chúng ta có quá nhiều chú thích về cơ bản lại làm điều tương tự.

Vì vậy, câu hỏi của tôi là:

Sự khác biệt chính xác giữa các chú thích đó là gì, làm thế nào để đặt chúng chính xác và tại sao?

Từ clang tài liệu :

Các vòng loại nullable (loại) biểu thị cho dù giá trị của một loại con trỏ đã cho có thể là null ( _Nullablevòng loại), không có nghĩa được xác định cho null ( _Nonnullvòng loại) hoặc mục đích của null không rõ ràng ( _Null_unspecifiedvòng loại) . Bởi vì các vòng loại nullable được thể hiện trong hệ thống loại, chúng chung chung hơn các thuộc tính nonnullvà returns_nonnullthuộc tính, cho phép một người thể hiện (ví dụ) một con trỏ nullable cho một mảng các con trỏ không khác nhau. Vòng loại Nullability được viết ở bên phải của con trỏ mà chúng áp dụng.

và

Trong Objective-C, có một cách viết thay thế cho các vòng loại nullable có thể được sử dụng trong các phương thức và thuộc tính của Objective-C bằng cách sử dụng các từ khóa không nhạy cảm theo ngữ cảnh

Vì vậy, đối với các trả về phương thức và các tham số, bạn có thể sử dụng các phiên bản được gạch dưới hai lần __nonnull/ __nullable/ __null_unspecifiedthay vì các phiên bản đơn lẻ hoặc thay vì các phiên bản không được bảo vệ. Sự khác biệt là những cái đơn lẻ và gấp đôi cần được đặt sau định nghĩa kiểu, trong khi những cái không được thiếu cần phải được đặt trước định nghĩa kiểu.

Do đó, các khai báo sau là tương đương và đúng:

- (nullable NSNumber *)result
- (NSNumber * __nullable)result
- (NSNumber * _Nullable)result

Đối với tham số:

- (void)doSomethingWithString:(nullable NSString *)str
- (void)doSomethingWithString:(NSString * _Nullable)str
- (void)doSomethingWithString:(NSString * __nullable)str

Đối với tài sản:

@property(nullable) NSNumber *status
@property NSNumber *__nullable status
@property NSNumber * _Nullable status

Tuy nhiên, mọi thứ trở nên phức tạp khi các con trỏ hoặc khối kép trả về một cái gì đó khác với khoảng trống có liên quan, vì những cái không gạch dưới không được phép ở đây:

- (void)compute:(NSError *  _Nullable * _Nullable)error
- (void)compute:(NSError *  __nullable * _Null_unspecified)error;
// and all other combinations

Tương tự với các phương thức chấp nhận các khối làm tham số, xin lưu ý rằng nonnull/ nullablevòng loại áp dụng cho khối và không phải là kiểu trả về của nó, do đó, các cách sau là tương đương:

- (void)executeWithCompletion:(nullable void (^)())handler
- (void)executeWithCompletion:(void (^ _Nullable)())handler
- (void)executeWithCompletion:(void (^ __nullable)())handler

Nếu khối có giá trị trả về, thì bạn buộc phải tham gia một trong các phiên bản gạch dưới:

- (void)convertObject:(nullable id __nonnull (^)(nullable id obj))handler
- (void)convertObject:(id __nonnull (^ _Nullable)())handler
- (void)convertObject:(id _Nonnull (^ __nullable)())handler
// the method accepts a nullable block that returns a nonnull value
// there are some more combinations here, you get the idea

Để kết luận, bạn có thể sử dụng một trong hai, miễn là trình biên dịch có thể xác định mục để gán vòng loại.

Từ blog Swift :

Tính năng này được phát hành lần đầu tiên trong Xcode 6.3 với các từ khóa __nullable và __nonnull. Do các xung đột tiềm ẩn với các thư viện của bên thứ ba, chúng tôi đã thay đổi chúng trong Xcode 7 thành _Nullable và _Nullull bạn thấy ở đây. Tuy nhiên, để tương thích với Xcode 6.3, chúng tôi đã xác định trước các macro __nullable và __nonnull để mở rộng sang tên mới.

Tôi thực sự thích bài viết này , vì vậy tôi chỉ hiển thị những gì tác giả đã viết: https://swiftunboxed.com/interop/objc-nullability-annotations/

• null_unspecified:cầu nối đến một Swift tùy chọn không được bao bọc tùy chọn. Đây là mặc định .
• nonnull: giá trị sẽ không bằng không; cầu đến một tài liệu tham khảo thường xuyên.
• nullable: giá trị có thể bằng 0; cầu đến một tùy chọn.
• null_resettable: giá trị không bao giờ có thể bằng 0 khi đọc, nhưng bạn có thể đặt nó thành 0 để đặt lại. Chỉ áp dụng cho các thuộc tính.

Các ký hiệu ở trên, sau đó khác nhau cho dù bạn sử dụng chúng trong ngữ cảnh của các thuộc tính hoặc hàm / biến:

Tác giả của bài viết cũng cung cấp một ví dụ hay:

// property style
@property (nonatomic, strong, null_resettable) NSString *name;

// pointer style
+ (NSArray<NSView *> * _Nullable)interestingObjectsForKey:(NSString * _Nonnull)key;

// these two are equivalent!
@property (nonatomic, strong, nullable) NSString *identifier1;
@property (nonatomic, strong) NSString * _Nullable identifier2;

Rất tiện dụng là

NS_ASSUME_NONNULL_BEGIN 

và kết thúc với

NS_ASSUME_NONNULL_END 

Điều này sẽ vô hiệu hóa nhu cầu về mức mã 'nullibis' :-) vì sẽ hợp lý khi cho rằng mọi thứ đều không có giá trị ( nonnullhoặc _nonnullhoặc __nonnull) trừ khi có ghi chú khác.

Thật không may, cũng có ngoại lệ cho điều này ...

• typedefs không được coi là __nonnull(lưu ý, nonnulldường như không hoạt động, phải sử dụng nó là anh em cùng cha khác mẹ xấu xí)
• id *cần một nullibi rõ ràng nhưng wow thuế tội lỗi ( _Nullable id * _Nonnull<- đoán điều đó có nghĩa là gì ...)
• NSError ** luôn luôn được coi là nullable

Vì vậy, với các ngoại lệ cho các ngoại lệ và các từ khóa không nhất quán gợi ra chức năng tương tự, có lẽ cách tiếp cận là sử dụng các phiên bản __nonnull/ __nullable/ __null_unspecifiedvà trao đổi xấu xí khi người khiếu nại phàn nàn ...? Có lẽ đó là lý do tại sao chúng tồn tại trong các tiêu đề của Apple?

Thật thú vị, một cái gì đó đã đưa nó vào mã của tôi ... Tôi ghê tởm mã dưới (anh chàng kiểu Apple C ++ cũ) nên tôi hoàn toàn chắc chắn rằng tôi đã không gõ những thứ này nhưng chúng xuất hiện (một ví dụ về một số):

typedef void ( ^ DidReceiveChallengeBlock ) ( NSURLSessionAuthChallengeDisposition disposition,
                                          NSURLCredential * __nullable credential );

Và thú vị hơn nữa, khi nó chèn __nullable là sai ... (eek @!)

Tôi thực sự muốn tôi chỉ có thể sử dụng phiên bản không gạch dưới nhưng dường như nó không bay với trình biên dịch vì điều này được gắn cờ là một lỗi:

typedef void ( ^ DidReceiveChallengeBlock ) ( NSURLSessionAuthChallengeDisposition disposition,
                                          NSURLCredential * nonnull  credential );