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

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

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

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

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

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

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

隐式解包装可选(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
}

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

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

在我描述隐式拆包可选项的用例之前，你应该已经理解了什么是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的变量当然不会造成太大伤害。