ios - 为什么 Swift 2 更喜欢强制解包而不是可选值？

Question

我不再看到 Xcode 提示某些东西需要可选值(“？”)。现在它总是被强制展开(爆炸“!”)。当我们现在强制解包时，是否有任何理由再使用可选值？

Answer 1

当您写道您不再看到 Xcode 提示“某些东西需要可选值。现在它总是被强制展开” 时，我真的不知道您的意思。这两句话相互矛盾:

• 您可以随心所欲地使用非可选变量，但是一旦您了解了使用它们的所有好处，可选变量就会非常好。
• 如果您有一个不是可选的属性，那么根据定义，它不需要任何解包。

也许您提到的是，当您实际强制解包 可选值时，Xcode 似乎很少提示，或者，作为 Xcode 的一个坏习惯，提示您强制解包以避免编译时错误。这通常是因为 Xcode 在编译时无法知道您刚刚编写的代码会在运行时破坏您的应用程序。

Xcode 的“智能提示”有时似乎只有一个目的:即消除编译时错误。如果您尝试将 String? 类型(可选 String)的值分配给 String 类型，Xcode 将提示您编译器错误并且询问您是否要添加强制解包运算符 !。你说智能 Xcode？嗯，Xcode 对很多事情都有好处，但是决定你如何解开你的选项是，无论如何，其中之一。因此，即使 Xcode 会提示您进行各种操作:如果您可以使用可选链接，那就去做吧。

当然，也可能有异常(exception)。对于 MVC 设计范例的 Controller 部分，您通常使用 as! 运算符进行“强制转换”(转换)，Xcode 有时会告诉您明确使用 as! 而不是 as，例如“您的意思是as! ...？”。在这些情况下，Xcode 有时实际上可以知道它在做什么，并推断出您正在尝试将自定义 UIViewController 类实例转换为类型 UIViewController，即，到它的父类。我想说这可能是我使用“强制”标记 ! 的少数几次之一；强制转换为我 100% 确定可转换的类型。

• > The as! operator

但让我们离开类型转换/强制转换的主题，继续讨论一般的可选类型、包装和可选链接。

---

通常，您应该避免强制解包，除非您明确知道您解包的实体将不为零。对于一般的类属性、变量等，鉴于你按照你的方式陈述这个问题，我会给你以下建议:

If you can use conditional unwrapping (if-let, guard-let, nil coalescing operator ??), then don't use forced unwrapping (!).

下面是强制展开的危险示例。您可以将第一个 if 子句 (if arc4random...) 视为您使用命令式编程技术编写的某个程序的任何较小或较大的部分:我们不直到运行时才真正详细了解“名称”的结果，而我们的编译器在这里无法真正帮助我们。

var name : String?

/* 'name' might or might not have a non-nil 
    value after this if clause */
if arc4random_uniform(2) < 1 {
    name = "David"
}

/* Well-defined: us an if-let clause to try to unwrap your optional */
if let a = name {
    print("Hello world "+a)
        /* Very well-behaved, we did a safe
           unwrap of 'name', if not nil, to constant a */

    print("Hello world "+name!)
        /* Well... In this scope, we know that name is, 
           for a fact, not nil. So here, a force unwrap
           is ok (but not needed). */
}

let reallyGiveMeThatNameDammit = name!
    /* NOT well-defined. We won't spot this at compile time, but
       if 'name' is nil at runtime, we'll encounte a runtime error */

我建议您阅读可选链，这是 Swift 中的一个重要主题。

• > Swift Language Guide - Optional Chaining