隐式打开可选选项是一种实用的妥协，可以使混合环境中的工作与现有的Cocoa框架及其约定进行互操作更加愉快，同时还允许逐步迁移到更安全的编程范式——没有空指针——由Swift编译器强制执行。

Swift的书，在基础章节，部分隐式打开可选项说:

Implicitly unwrapped optionals are useful when an optional’s value is confirmed to exist immediately after the optional is first defined and can definitely be assumed to exist at every point thereafter. The primary use of implicitly unwrapped optionals in Swift is during class initialization, as described in Unowned References and Implicitly Unwrapped Optional Properties. … You can think of an implicitly unwrapped optional as giving permission for the optional to be unwrapped automatically whenever it is used. Rather than placing an exclamation mark after the optional’s name each time you use it, you place an exclamation mark after the optional’s type when you declare it.

This comes down to use cases where the non-nil-ness of properties is established via usage convention, and can not be enforced by compiler during the class initialization. For example, the UIViewController properties that are initialized from NIBs or Storyboards, where the initialization is split into separate phases, but after the viewDidLoad() you can assume that properties generally exist. Otherwise, in order to satisfy the compiler, you had to be using the forced unwrapping, optional binding or optional chaining only to obscure the main purpose of the code.

Swift书中的上述部分也参考了自动引用计数章节:

然而，还有第三种情况，在这种情况下，两个属性都应该有一个值，并且在初始化完成后，两个属性都不应该为nil。在这种情况下，将一个类上的无主属性与另一个类上隐式展开的可选属性结合起来是很有用的。 这使得在初始化完成后可以直接访问这两个属性(不需要可选的展开)，同时仍然避免了引用循环。

这归结于不是垃圾收集语言的怪癖，因此保留周期的破坏是由程序员来承担的，隐式地打开可选选项是隐藏这个怪癖的工具。

这涵盖了“何时在代码中使用隐式展开的可选选项?””的问题。作为应用程序开发人员，您将在用Objective-C编写的库的方法签名中遇到它们，而Objective-C没有表达可选类型的能力。

在Cocoa和Objective-C中使用Swift，部分使用nil:

Because Objective-C does not make any guarantees that an object is non-nil, Swift makes all classes in argument types and return types optional in imported Objective-C APIs. Before you use an Objective-C object, you should check to ensure that it is not missing. In some cases, you might be absolutely certain that an Objective-C method or property never returns a nil object reference. To make objects in this special scenario more convenient to work with, Swift imports object types as implicitly unwrapped optionals. Implicitly unwrapped optional types include all of the safety features of optional types. In addition, you can access the value directly without checking for nil or unwrapping it yourself. 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. As a result, you should always check and unwrap an implicitly unwrapped optional yourself, unless you are sure that the value cannot be missing.

.．.在这里的另一边

Apple在Swift编程语言中给出了一个很好的例子——>自动引用计数——>在类实例之间解决强引用循环——>无主引用和隐式未包装可选属性

class Country {
    let name: String
    var capitalCity: City! // Apple finally correct this line until 2.0 Prerelease (let -> var)
    init(name: String, capitalName: String) {
        self.name = name
        self.capitalCity = City(name: capitalName, country: self)
    }
}

class City {
    let name: String
    unowned let country: Country
    init(name: String, country: Country) {
        self.name = name
        self.country = country
    }
}

City的初始化式是从Country的初始化式中调用的。但是，Country的初始化式不能将self传递给City初始化式，直到一个新的Country实例完全初始化，如两阶段初始化中所述。 为了满足这一要求，您将Country的capitalCity属性声明为隐式展开的可选属性。

一行(或几行)简单的示例并不能很好地涵盖可选项的行为——是的，如果你声明一个变量并立即为它提供一个值，那么可选项就没有意义了。

到目前为止我见过的最好的情况是在对象初始化之后发生的设置，然后是“保证”在该设置之后的使用，例如在视图控制器中:

class MyViewController: UIViewController {

    var screenSize: CGSize?

    override func viewDidLoad {
        super.viewDidLoad()
        screenSize = view.frame.size
    }

    @IBAction printSize(sender: UIButton) {
        println("Screen size: \(screenSize!)")
    }
}

我们知道printSize将在视图加载后被调用——它是一个连接到视图内控件的操作方法，并且我们确保不会以其他方式调用它。因此，我们可以使用!来节省一些可选的检查/绑定。Swift不能识别这个保证(至少在Apple解决停止问题之前)，所以你告诉编译器它存在。

不过，这在一定程度上破坏了类型安全。如果你的“保证”并不总是有效，那么任何你拥有隐式展开可选选项的地方都可能导致应用崩溃，所以这是一个需要谨慎使用的功能。此外，使用!总是让人觉得你在大喊大叫，没人喜欢这样。

如果你确定从可选对象返回值而不是nil，隐式解包装可选对象用于直接从可选对象捕获这些值，而非可选对象则不能。

//Optional string with a value
let optionalString: String? = "This is an optional String"

//Declaration of an Implicitly Unwrapped Optional String
let implicitlyUnwrappedOptionalString: String!

//Declaration of a non Optional String
let nonOptionalString: String

//Here you can catch the value of an optional
implicitlyUnwrappedOptionalString = optionalString

//Here you can't catch the value of an optional and this will cause an error
nonOptionalString = optionalString

这就是使用的区别

let someString:字符串!然后让someString: String

隐式打开可选选项是一种实用的妥协，可以使混合环境中的工作与现有的Cocoa框架及其约定进行互操作更加愉快，同时还允许逐步迁移到更安全的编程范式——没有空指针——由Swift编译器强制执行。

Swift的书，在基础章节，部分隐式打开可选项说:

Implicitly unwrapped optionals are useful when an optional’s value is confirmed to exist immediately after the optional is first defined and can definitely be assumed to exist at every point thereafter. The primary use of implicitly unwrapped optionals in Swift is during class initialization, as described in Unowned References and Implicitly Unwrapped Optional Properties. … You can think of an implicitly unwrapped optional as giving permission for the optional to be unwrapped automatically whenever it is used. Rather than placing an exclamation mark after the optional’s name each time you use it, you place an exclamation mark after the optional’s type when you declare it.

This comes down to use cases where the non-nil-ness of properties is established via usage convention, and can not be enforced by compiler during the class initialization. For example, the UIViewController properties that are initialized from NIBs or Storyboards, where the initialization is split into separate phases, but after the viewDidLoad() you can assume that properties generally exist. Otherwise, in order to satisfy the compiler, you had to be using the forced unwrapping, optional binding or optional chaining only to obscure the main purpose of the code.

Swift书中的上述部分也参考了自动引用计数章节:

然而，还有第三种情况，在这种情况下，两个属性都应该有一个值，并且在初始化完成后，两个属性都不应该为nil。在这种情况下，将一个类上的无主属性与另一个类上隐式展开的可选属性结合起来是很有用的。 这使得在初始化完成后可以直接访问这两个属性(不需要可选的展开)，同时仍然避免了引用循环。

这归结于不是垃圾收集语言的怪癖，因此保留周期的破坏是由程序员来承担的，隐式地打开可选选项是隐藏这个怪癖的工具。

这涵盖了“何时在代码中使用隐式展开的可选选项?””的问题。作为应用程序开发人员，您将在用Objective-C编写的库的方法签名中遇到它们，而Objective-C没有表达可选类型的能力。

在Cocoa和Objective-C中使用Swift，部分使用nil:

Because Objective-C does not make any guarantees that an object is non-nil, Swift makes all classes in argument types and return types optional in imported Objective-C APIs. Before you use an Objective-C object, you should check to ensure that it is not missing. In some cases, you might be absolutely certain that an Objective-C method or property never returns a nil object reference. To make objects in this special scenario more convenient to work with, Swift imports object types as implicitly unwrapped optionals. Implicitly unwrapped optional types include all of the safety features of optional types. In addition, you can access the value directly without checking for nil or unwrapping it yourself. 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. As a result, you should always check and unwrap an implicitly unwrapped optional yourself, unless you are sure that the value cannot be missing.

.．.在这里的另一边

在我描述隐式拆包可选项的用例之前，你应该已经理解了什么是Swift中的可选项和隐式拆包可选项。如果你不知道，我建议你先阅读我关于可选选项的文章

何时使用隐式展开可选

创建隐式解包装可选对象有两个主要原因。所有这些都与定义一个在nil时永远不会被访问的变量有关，否则，Swift编译器总是会强制你显式地打开一个Optional。

1. 初始化时不能定义的常量

在初始化完成之前，每个成员常量都必须有一个值。有时，一个常量在初始化过程中不能用正确的值初始化，但在被访问之前仍然可以保证它有一个值。

使用可选变量可以解决这个问题，因为可选变量会自动初始化为nil，它最终包含的值仍然是不可变的。然而，不断地展开一个确定不是nil的变量可能是一件痛苦的事情。隐式打开可选选项实现了与可选选项相同的好处，额外的好处是不需要在所有地方显式打开它。

一个很好的例子是，一个成员变量不能在UIView子类中初始化，直到视图被加载:

class MyView: UIView {
    @IBOutlet var button: UIButton!
    var buttonOriginalWidth: CGFloat!

    override func awakeFromNib() {
        self.buttonOriginalWidth = self.button.frame.size.width
    }
}

这里，在视图加载之前不能计算按钮的原始宽度，但是您知道awakeFromNib将在视图上的任何其他方法(除了初始化)之前被调用。与其在整个类中强制显式地展开该值，不如将其声明为隐式未包装可选值。

2. 当你的应用程序不能从一个变量为nil恢复

这应该是非常罕见的，但如果你的应用程序不能继续运行，如果一个变量是nil访问时，这将是浪费时间的麻烦测试它为nil。通常情况下，如果你有一个条件必须为真，你的应用程序才能继续运行，你会使用断言。隐式解包装可选对象有一个内置于nil的断言。即使这样，如果可选对象为nil，最好还是展开可选对象，并使用更具描述性的断言。

何时不使用隐式解包装可选参数

1. 惰性计算的成员变量

有时你有一个成员变量不应该为nil，但在初始化时不能将它设置为正确的值。一种解决方案是使用隐式Unwrapped Optional，但更好的方法是使用惰性变量:

class FileSystemItem {
}

class Directory : FileSystemItem {
    lazy var contents : [FileSystemItem] = {
        var loadedContents = [FileSystemItem]()
        // load contents and append to loadedContents
        return loadedContents
    }()
}

现在，直到第一次访问成员变量时才初始化成员变量内容。这使类有机会在计算初始值之前进入正确的状态。

注意:这似乎与上面的第一条相矛盾。然而，这里有一个重要的区别。上面的buttonOriginalWidth必须在viewDidLoad期间设置，以防止任何人在访问属性之前更改按钮宽度。

2. 其他地方

在大多数情况下，隐式打开可选选项应该避免，因为如果错误地使用，你的整个应用程序将在nil时被访问时崩溃。如果你不确定一个变量是否可以为nil，总是默认使用普通的Optional。解开一个从不为nil的变量当然不会造成太大伤害。