我对此感到很困惑。如果我们以 UITableView 中的方法 cellForRowAtIndexPath: 为例，它的方法签名是:
func cellForRowAtIndexPath(_ indexPath: NSIndexPath!) -> UITableViewCell!
它的返回值为:
An object representing a cell of the table or nil if the cell is not visible or indexPath is out of range.
这听起来像是使用标准可选的完美理由。事实上，由于 Objective-C 中所有基于指针的类型都可以是 nil...似乎所有 Objective-C 指针类型都应该作为标准可选类型导入是有道理的。
我从 WWDC 的谈话中了解到，对于隐式解包的可选值，他们是这样说的:
- 可以显式测试 nil
- 可以直接访问底层值的属性/方法
- 可以隐式转换为其基础值
来自 Apple 的 Using Swift with Cocoa and Objective-C :
When you access the value in this kind of optional type without safely unwrapping it first, the implicitly unwrapped optional checks whether the value is missing. If the value is missing, a runtime error occurs.
因此，他们没有将可能为 nil 的值作为可选值导入 Swift 中，而是决定将其导入为声明这永远不应该为 nil 的东西……但可能是吗？听起来他们这样做完全否定了 Swift 中用于 Objective-C API 的可选类型的安全性。我似乎缺少什么？
他们认为运行时错误更好，而不是给出编译时错误或警告？这非常令人困惑。
考虑到似乎没有什么可以回答我所看到的这个问题......我认为这对其他人来说是显而易见的，我只是没有看到但是......为什么会这样？
这真的只是为了避免人们在 Swift 中使用 Objective-C API 时使用 if let 或可选链，还是其他什么东西？
最佳答案
当你在 Swift 中创建一个隐式解包的可选时，并不意味着它总是非 nil:它只是意味着你告诉编译器当你访问它们的属性时，你希望该对象是非 nil .您引用的对象可以明确检查 nil ;将其设置为 nil也不会导致异常，除非您之后尝试访问它的任何属性。
当 Apple 对参数使用隐式解包选项时
func tableView(_ tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell!
功能，它们让您节省一些额外费用 if - let .在这种情况下，他们知道他们永远不会给你一个nil。 ;在其他情况下，他们不知道，他们希望您 nil -检查对象。
它们允许您返回 nil ， 也。由他们检查 nil 的结果，当然，除非您决定自己调用该函数。虽然我想不出一个合理的理由来打电话 cellForRowAtIndexPath从您自己的代码中，如果您确实进行了调用，则您有责任检查 nil 的返回值.
如果您考虑制作参数的替代方案 UITableView?和 NSIndexPath?相反，所有实现都必须在 tableView 之后使用感叹号和 indexPath ，或使用 if - let成语。与此选择相比，隐式解包类型看起来是更好的选择。
关于ios - 为什么 Objective-C API 会返回隐式解包的可选值？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24728235/