“…in Swift there’s a strong distinction between optional and
non-optional references, e.g. NSView vs. NSView?, while Objective-C
represents boths of these two types as NSView *. Because the Swift
compiler can’t be sure whether a particular NSView * is optional or
not, the type is brought into Swift as an implicitly unwrapped
optional, NSView!”
这是否意味着之前在声明Objective-C方法为在Swift中隐式解包可选的可选项时,它实际上可能会崩溃(因为使用隐式解包的可选项声明的某些方法可能会返回nil)？或者,Apple是否确保只有那些绝对不返回nil的Objective-C方法被声明为隐式解包的可选项？
Apple的框架并不特别.在开始时,您在Swift中使用Objective-C的所有内容(每个对象)都是一个隐式解包的可选项.那是因为Objective-C中的每个指针都可能返回nil.实际上,即使在Objective-C可空性注释的时代,注释为nonnull的方法也不可能返回nil. Objective-C不强制执行可空性规则,它只是提供了一种注释代码的方法,以便从Swift中使用它更安全.在Apple的框架中,我敢打赌,这是一个非常安全的赌注,你不会有这个问题.或者,如果你这样做,Xcode的下一个版本将修复它.
但同样,来自Objective-C库和框架的隐式解包选项没有什么特别之处.隐式解包的可选项告诉您的唯一事情是框架作者尚未努力注释其库(您不能在已注释的库中隐式包含未包装的选项).是的,这些隐式解包的选项可能是零,它们可能会使您的应用程序崩溃.
在Apple的情况下,如果由于某种原因,你在不同的项目中使用Xcode 7和Xcode 6,如果你采取了Xcode 7的更新注释声明为非可选的东西,那么假设在Xcode中隐式解包的可选版本6永远不会是零可能会成功.但是如果你在Xcode 7中选择了一个可选的东西,假设从Xcode 6隐式展开的版本永远不会是零,可能会有很大的崩溃你的应用程序的可能性.
最终,在Swift中,我们对隐式展开的选项的使用应该是少之又少.隐式展开的选项的主要用途应该主要保留给在返回类初始化之前无法设置的类属性(例如,视图控制器中的@IBOutlets).否则,它们很容易成为Stack Overflow上众多“意外发现的零”问题的来源.
对于“为什么要返回隐式解包的可选而不是可选？”的问题,有几点……
首先,这是一个语言设计问题.我不是在Objective-C或Swift语言设计团队中,这些团队中的任何人都不太可能会停下来回答这个问题……
其次,这就是语言的互操作性.没有添加任何可空性注释的任何Objective-C文件都将被视为在Swift中一切都是隐式解包的可选项.
第三,隐式选项的原因是它减少了很多可选的if语句的冗长,而不保证变量实际上是非零的.造成这种情况的大部分原因可能是因为你认为大多数这些方法实际上永远不会返回零.
第四,如果您知道哪些机会有空,哪些机会没有,您实际上可以继续编写Swift代码,以处理对Objective-C代码注释方式的假设.
例如,使用隐式展开的可选项,当然,您可以将其视为非可选项,并删除与展开相关的一些次要详细程度.
另外,如果您认为它可能是零,则使用隐式展开的可选项,所有可选的展开内容仍然可以使用它.
例：
override func someFunc(implicitVal: String!) -> String {
return implicitVal ?? "It was nil!"
}
override func someOtherFunc(implicitVal: String!) -> String {
return implicitVal
}
如果我们将它们全部视为可选项,则第二个示例将不起作用
如果我们将它们假设为非选项,那么第一个例子将不起作用.
隐式解包的选项允许Swift开发人员自由地将它们视为对价值为零的可能性做出正确假设.