为什么Objective-C API会隐式返回未包装的选项？

Question

我对此相当困惑。如果我们以UITableView中的方法cell ForRowAtIndexPath：为例，它的方法签名是：

func cellForRowAtIndexPath(_ indexPath: NSIndexPath!) -> UITableViewCell!

其返回值为：

表示表中某个单元格的对象，如果该单元格不可见或indexPath超出范围，则表示nil。

这听起来是使用标准可选选项的完美理由。事实上，由于Objective-C中所有基于指针的类型都可以为零。。。似乎所有Objective-C指针类型都应该作为标准选项导入是有道理的。

我从WWDC的谈话中了解到，他们说对于隐式展开的选项：

• 可明确测试为零
• 可以直接访问基础值的属性/方法
• 可以隐式转换为其基础值

苹果公司将Swift与可可粉和Objective-C结合使用：

当您访问这种可选类型中的值而没有首先安全地展开它时，隐式展开的可选项会检查该值是否丢失。如果值丢失，则会发生运行时错误。

因此，他们没有将可能为nil的值作为可选项导入Swift，而是决定将其导入为声明永远不应该为nil的内容......但可能是？听起来他们这样做完全否定了Swift for Objective-C API中可选类型的安全性。我似乎错过了什么？

他们没有给出编译时错误或警告，而是认为运行时错误更好？这很令人困惑。

考虑到似乎没有什么能回答我所看到的这个问题。。。我想这对其他人来说是显而易见的，我只是没有看到，但。。。为什么是这样？

当人们在Swift中使用Objective-C API时，它真的只是为了避免人们使用if let或可选的链接，还是其他什么？

Answer 1

以下是格雷格·帕克在lists.swift.org的swift用户中的回答：

作为隐式展开的可选导入是一种可用性折衷。大多数Objective-C指针实际上从来都不是零。如果指针为nil，而作者没有检查，则进程会故意停止。这并不比编写Objective-C代码时的行为更糟糕。IUO进口只是权宜之计。从长远来看，每个Objective-C接口都应该被显式注释，以便Swift能够更精确地导入它们。在您自己的代码中，您可以在头文件中使用NS_asked_NONNULL_BEGIN/END。这些标记中的每个未注释的对象指针都是非空的。

Answer 2

当您在Swift中创建隐式展开可选项时，这并不意味着它总是非nil：这意味着您告诉编译器，当您访问它们的属性时，您希望对象是非nil。可以显式检查您引用的对象是否为nil；将其设置为nil也不会导致异常，除非您在此之后尝试访问其任何属性。

当Apple对参数使用隐式展开选项时

func tableView(_ tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell!

如果-let，它们可以让你节省一些额外的。在这种情况下，他们知道他们永远不会给你一个nil；在其他情况下，他们不知道，他们希望你检查对象。

它们也允许您返回nil。当然，除非您决定自己调用该函数，否则由他们检查nil的结果。虽然我想不出从您自己的代码调用CellForRowatineXpath的正当理由，但如果您确实进行了调用，您将负责检查nil的返回值。

如果您考虑让参数UITableView 和nsindepath tableView和indepath之后使用感叹号，或者使用if-let习惯用法。与此选择相比，隐式展开类型看起来是更好的选择。