为什么Swift隐式展开选项为“nil”？

Question

self.presentTextInputControllerWithSuggestions(nil, allowedInputMode: WKTextInputMode.Plain) { (results:[AnyObject]!) -> Void in
    // results can be nil
    if let speech = results.first as? String {
        debugPrint(speech)
    }
}

请原谅我的无知，我恐怕错过了一些基本的选项理解。我的印象是（隐式展开的可选指示符）保证该类型的变量不为零。然而，这个非常简单的Apple API很少会返回我nil。

这是一个意外的错误还是Optionals规范的一部分？因为如果这是规范的一部分，我不明白为什么会有选项，而不是变量可以存在或nil。

Answer 1

不，这个符号 不能保证变量不是零。

swift中的选项很棘手。

假设您有以下字符串类型的变量

var name: String?

这不是一根绳子。这是一个可选字符串，这是另一回事。

然而，以下几点：

var name: String!

是一个隐式展开的可选项，这意味着调用名称将始终给出字符串，而不是可能为nil的可选字符串。

如果希望代码在可选项为nil时崩溃，通常使用隐式展开可选项。

Answer 2

每当你看到一个带有的方法签名 nil。

在大多数情况下，参数将是隐式展开的可选项，因为它来自一个尚未更新以说明Objective-C可空性注释的Objective-C库（Objective-C源代码文件用于告诉Swift参数是否应该是可选的）。

Objective-C不支持optionals的想法。

如果这是来自Apple库，那么他们发布Xcode更新来解决这个问题并将参数更改为非可选或可选参数只是时间问题。苹果没有在其参数中保留任何隐含未包装选项的长期计划。

Answer 3

我的印象是（隐式展开的可选指示符）保证该类型的变量不为零。

恐怕这是一个错误的印象。隐式展开的选项很可能是nil。只有没有用任何可选限定符声明的东西，既不是？也不是！，才保证是非nil。

所以：

var definitelyCouldBeNilForcedToCheck: String?
var mightBeNilButProbablyNotBECAREFUL: String!
var definitelyNotEverNil: String

隐式展开选项有两个用例：

>

当你绝对肯定你的价值不会为零时，除非是在非常可控的情况下。例如，假设您有一个函数，它在可失败的初始值设定项中进行了一些处理。这样地：

class FileHandler {
    let fileHandle: SomeFileHandleType!

    init?(fileName: String) {
        fileHandle = open(fileName)
        if fileHandle == nil { return nil }
    }

    deinit {
        if fileHandle != nil {
            fileHandle.close()
        }
    }

    func variousMethods() {
        // can just use fileHandle without bothering about
        // unwrapping it, because it cannot possibly be nil
        // based on how you’ve written your code
    }
}

当你有大量的Objective-C（比如Cocoa或UIKit）时，你不知道什么时候返回某个指针，它是否可以是nil。大多数情况下，你认为它可能不是，让你的API用户不断地打开东西真的很烦人，但是，你也不确定它不可能是零，你希望他们阅读文档。但他们可能会忘记，但你能做什么？最终，您将审核所有函数，然后将它们设置为可选值或不可为空的值。