考虑一个对象在构造和配置时可能具有nil属性，但在构造和配置后是不可变的且非nil的情况(NSImage通常是这样处理的，尽管在这种情况下，有时改变仍然是有用的)。隐式地打开可选选项可以很好地清理代码，而且安全性损失相对较低(只要有一个保证，它就是安全的)。

(编辑)需要明确的是:常规的可选选项几乎总是更可取的。

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

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

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

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

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

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

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

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

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

哪个不如

println("\(value!)")

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

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

Swift书，在基础章，节隐式解包装可选项说:

当一个可选项的值在该可选项第一次定义后立即被确认存在，并且可以肯定地假设该可选项在此后的每一点上都存在时，隐式未包装可选项是有用的。在Swift中隐式解包装可选项的主要用途是在类初始化期间，如无主引用和隐式展开可选属性所述。
,
您可以将隐式解包装的可选项视为授予可选项在使用时自动解包装的权限。不是每次使用时在可选对象的名称后面加上一个感叹号，而是在声明时在可选对象的类型后面加上一个感叹号

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

然而，还有第三种情况，在这种情况下，两个属性都应该有一个值，并且在初始化完成后，两个属性都不应该是nil。在这种情况下，将一个类上的无主属性与另一个类上隐式展开的可选属性结合起来是很有用的。

这使得在初始化完成后可以直接访问这两个属性(不需要可选的展开)，同时仍然避免了引用循环。

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

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

从使用Swift与Cocoa和Objective-C, section 工作与nil:

因为Objective-C不保证对象是非空的，Swift在导入的Objective-C api中使参数类型和返回类型中的所有类都是可选的。在使用Objective-C对象之前，您应该检查以确保它没有丢失。

在某些情况下，你可能会绝对确定Objective-C方法或属性永远不会返回nil对象引用。为了使这个特殊场景中的对象更方便使用，Swift将对象类型导入为隐式打开的可选项。隐式打开的可选类型包括可选类型的所有安全特性。此外，您可以直接访问该值，而无需检查nil或自己展开它。当您访问这种可选类型的值时，没有首先安全地展开它，隐式展开的可选检查该值是否丢失。如果缺少该值，则会发生运行时错误。因此，您应该始终自己检查并展开隐式展开的可选选项，除非您确定该值不会丢失。

.．.然后在这里放置

在我描述隐式拆包可选项的用例之前，你应该已经理解了什么是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测试它。通常，如果你有一个条件必须为真才能让你的应用程序继续运行，你可以使用assert。隐式解包装可选对象有一个内置于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
}()
}

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

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

2. 其他地方

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

苹果给出了一个很好的例子: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实例完全初始化之前，Country的初始化式不能将self传递给City初始化式，如两阶段初始化所述。

为了满足这一要求，将Country的capitalCity属性声明为隐式展开的可选属性。

如果你确定从可选对象返回值而不是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

这就是使用的区别

__abc0 __abc2 __abc1

我认为Optional对于这个构造来说是一个不好的名字，会让很多初学者感到困惑。

其他语言(例如Kotlin和c#)使用术语Nullable，这使得它更容易理解。

Nullable意味着你可以给这个类型的变量赋一个空值。所以如果它是Nullable<SomeClassType>，你可以给它赋空值，如果它只是SomeClassType，你不能。这就是Swift的工作方式。

为什么要使用它们?有时候你需要空值，这就是原因。例如，当您知道希望在类中有一个字段时，但是在创建该类的实例时不能将其分配给任何东西，但稍后会这样做。我就不举例子了，因为人们已经在这里提供了例子。我写这些只是为了表达我的意见。

顺便说一句，我建议你看看这在其他语言中是如何工作的，比如Kotlin和c#。

其他语言，如Java和Scala确实有__abc0，但它们的工作方式与Swift中的__abc0不同，因为Java和Scala的类型默认都是可空的。

总而言之，我认为这个功能应该在Swift中被命名为Nullable，而不是Optional…

Implicitly Unwrapped Optional (IUO)

它是Optional的一个语法糖，不强制程序员打开变量。它可以用于在two-phase initialization process和意味着非nil期间不能初始化的变量。这个变量本身表现为非nil值，但实际上是一个可选变量。一个很好的例子是- Interface Builder的outlet

Optional通常更可取

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
}