[FEATURE REQ] `assume_nullable` macro in LLVM & Objective C [Xcode 10]

Number:rdar://46839794 Date Originated:December 19 2018, 3:18 PM
Status: Resolved:
Product:LLVM / ObjC Product Version:
Classification: Reproducible:
As Xcode 7.x / LLVM introduced `NS_ASSUME_NONNULL_*` macros along with type nullability annotations, it would be really nice to provide a competing `NS_ASSUME_NULLABLE_*` macros in both LLVM and Objective C as well.

Legacy code is often written with no explicit knowledge about variable nullability state and it's way more likely to understand such properties as nullable by default. This would also greatly help porting an Objective C code without nullability annotations to be used and exported for Swift with no need to introduce force-unwrapped properties.

As there's no really convenient way to check the state of annotated properties in Objective C (even a `nonnull` property can be left with `nil` value f.e. after initialisation as there's no actual strict checking like in Swift), marking the code with “assume nonnull” can introduce runtime errors due to this lacking nullability check confidence. Marking such code as “assume nullable” (as we really used to think about the code that way and check it during the runtime) and optionally manually check only the strictly annotated nonnull properties would be a bit “safer” solution in such cases.


When importing ObjC headers with no NS_ASSUME_ marks, all properties are implicitly handled as potentially-nullable and imported as force-unwrapped. That's why I think having a possibility to explicitly mark it as nullable-by-default is the easier migration path as it's closer to what actually happens with no code change. How's marking the file as nonnull-by-default easier when there's a vital need to check all properties and either 1) mark them as nullable or 2) leave them as nonnull and check if it's actually true, when there's even no guarantee by the compiler/analyser?  I wouldn't argue a bit in case ObjC code could be type-checked as strongly and well as Swift, including the consistency, initialisers etc., but that's not the case.


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!