ios – 为什么Objective-C API返回隐式展开的可选项?

我对此感到困惑如果我们采用方法cellForRowAtIndexPath:在UITableView中,它的方法签名是:
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中所有基于指针的类型都可以为零,所以Objective-C指针类型应该以标准的可选方式导入.

我从WWDC的谈话中知道,他们说隐含的展开的可选项:

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

而从苹果的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.

所以,不是将可能的零价值引入Swift作为一个可选的,而是决定将它导入到这个东西,说明这不应该是零…但是可以吗?听起来他们完全否定了Swift for Objective-C API中可选类型的安全性.我似乎缺少什么?

而不是给出编译时错误或警告,他们决定运行时错误更好?这很混乱

考虑到没有什么似乎回答了我所看到的这个问题…我认为这是所有其他人明显的东西,我只是没有看到,但为什么是这样的?

如果在Swift中使用Objective-C API或者更多的东西,是否允许人们使用或选择性链接,这是否真的只是为了保护用户

解决方法

当您在Swift中进行隐式解除选择时,并不意味着它总是不为零:所有这一切意味着您告诉编译器,当您访问其属性时,您希望对象为非零.您引用的对象可以被明确地检查为零;将其设置为nil也不会引起异常,除非您尝试访问其中的任何属性.

当苹果使用隐式解包的可选参数时

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

功能,他们让你节省一些额外的if – let.在这种情况下,他们知道他们永远不会通过你一个零;在其他情况下,他们不知道,他们希望你没有检查对象.

他们也允许你返回零.检查结果为零,取决于您,除非您决定自己调用功能.虽然我不能想到一个有效的原因从你自己的代码调用cellForRowAtIndexPath,如果你打电话,你的责任是检查返回值为零.

如果您考虑使用参数UITableView的替代方法?和NSIndexPath?相反,所有实现都必须在tableView和indexPath之后使用感叹号,或者使用if-let成语.与此选择相比,隐含展开的类型看起来更好.

相关文章

UITabBarController 是 iOS 中用于管理和显示选项卡界面的一...
UITableView的重用机制避免了频繁创建和销毁单元格的开销,使...
Objective-C中,类的实例变量(instance variables)和属性(...
从内存管理的角度来看,block可以作为方法的传入参数是因为b...
WKWebView 是 iOS 开发中用于显示网页内容的组件,它是在 iO...
OC中常用的多线程编程技术: 1. NSThread NSThread是Objecti...