我对此感到困惑。以UITableView
中的cellForRowAtIndexPath:
方法为例,其方法签名如下:
func cellForRowAtIndexPath(_ indexPath: NSIndexPath!) -> UITableViewCell!
其返回值为:
一个代表表格单元的对象,如果单元格不可见或indexPath越界,则为nil。
这听起来像使用标准可选项的完美理由。事实上,由于Objective-C中所有基于指针的类型都可以是nil...因此,似乎将所有Objective-C指针类型导入为标准可选项是有意义的。
我知道从WWDC演讲中他们说对于隐式展开的可选项:
- 可以明确测试是否为nil
- 可以直接访问底层值的属性/方法
- 可以隐式转换为其底层值
来自苹果的“使用Swift与Cocoa和Objective-C”:
当您在没有安全解包它之前访问此类可选类型中的值时,隐式展开的可选项将检查该值是否丢失。如果缺少该值,将出现运行时错误。
因此,他们决定将可能为nil的值导入Swift作为某些声明此永远不会是nil的东西...但可能是?听起来,他们通过这种方式完全取消了Swift可选类型在Objective-C API中的安全性。我错过了什么吗?
他们为什么要这样做,而不是给出编译时错误或警告呢?这很困惑。
考虑到我没有看到任何回答这个问题的东西...我认为这对其他人来说显然是一个明显的问题,而我只是没有看到...为什么会这样呢?
这真的只是为了节省人们在Swift中使用Objective-C API时使用 if let
或可选链接的时间,还是其他原因?
nil
。 - newacctfunc laterDate(_ anotherDate: NSDate!) -> NSDate!
),它会返回一个隐式解包的NSDate。为什么不只是标准的可选NSDate,而是一个隐式解包的呢? - NickHnil
,因此必须是可选的。隐式解包使您在确定它不是nil
的情况下更加方便(如果您错了,它会抛出错误),就像在任何地方显式解包一样。如果您不确定它是否为nil
,仍然可以使用可选绑定和可选链接。因此,程序员可以选择适当的使用方式。这样,苹果就不必在整个API中显式注释可空/非可空。 - newacct