隐式可选项的基本原理很容易解释，首先看一下强制展开的基本原理。

强制展开可选对象(隐式或非隐式)，使用!操作符，意味着您确定您的代码没有错误，并且可选选项已经在它被打开的地方有一个值。没有!运算符，你可能只需要断言一个可选的绑定:

 if let value = optionalWhichTotallyHasAValue {
     println("\(value)")
 } else {
     assert(false)
 }

哪个不如

println("\(value!)")

现在，隐式可选项允许您表示拥有一个可选项，您希望在所有可能的流中，该可选项在展开时始终具有一个值。因此，它只是进一步帮助您-通过放松编写!每次打开，并确保运行时仍然会出错，以防您对流的假设是错误的。

隐式可选项的基本原理很容易解释，首先看一下强制展开的基本原理。

强制展开可选对象(隐式或非隐式)，使用!操作符，意味着您确定您的代码没有错误，并且可选选项已经在它被打开的地方有一个值。没有!运算符，你可能只需要断言一个可选的绑定:

 if let value = optionalWhichTotallyHasAValue {
     println("\(value)")
 } else {
     assert(false)
 }

哪个不如

println("\(value!)")

现在，隐式可选项允许您表示拥有一个可选项，您希望在所有可能的流中，该可选项在展开时始终具有一个值。因此，它只是进一步帮助您-通过放松编写!每次打开，并确保运行时仍然会出错，以防您对流的假设是错误的。

隐式解包装可选(IUO)

它是Optional的一种语法糖，不会强制程序员打开变量。它可以用于在两阶段初始化过程中不能初始化的变量，并暗示非nil。这个变量本身表现为非nil，但实际上是一个可选变量。一个很好的例子是- Interface Builder的outlet

可选的通常更可取

var implicitlyUnwrappedOptional: String! //<- Implicitly Unwrapped Optional
var nonNil: String = ""
var optional: String?

func foo() {
    //get a value
    nonNil.count
    optional?.count
    
    //Danderour - makes a force unwrapping which can throw a runtime error
    implicitlyUnwrappedOptional.count
    
    //assign to nil
//        nonNil = nil //Compile error - 'nil' cannot be assigned to type 'String'
    optional = nil
    implicitlyUnwrappedOptional = nil
}

隐式打开可选选项对于将属性表示为非可选属性非常有用，而实际上它需要是可选的。这通常是在两个相关对象(每个对象都需要对另一个对象的引用)之间“打结”所必需的。当两个引用实际上都不是可选的，但在初始化pair时，其中一个引用需要为nil时，这是有意义的。

例如:

// These classes are buddies that never go anywhere without each other
class B {
    var name : String
    weak var myBuddyA : A!
    init(name : String) {
        self.name = name
    }
}

class A {
    var name : String
    var myBuddyB : B
    init(name : String) {
        self.name = name
        myBuddyB = B(name:"\(name)'s buddy B")
        myBuddyB.myBuddyA = self
    }
}

var a = A(name:"Big A")
println(a.myBuddyB.name)   // prints "Big A's buddy B"

任何B实例都应该有一个有效的myBuddyA引用，所以我们不想让用户把它当作可选的，但是我们需要它是可选的，这样我们就可以在有a引用之前构造一个B。

然而!这种相互引用需求通常是紧耦合和糟糕设计的标志。如果您发现自己依赖于隐式展开的可选项，那么您可能应该考虑重构以消除交叉依赖。

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

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

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解决停止问题之前)，所以你告诉编译器它存在。

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

隐式打开可选选项是一种实用的妥协，可以使混合环境中的工作与现有的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.

.．.在这里的另一边