原文链接：http://alisoftware.github.io/swift/2015/09/14/thinking-in-swift-1-addendum/
作者：Olivier Halligon
原文日期：2015/09/14
在发布了我的系列文章"Swift编程思想"的第一部分之后，在Twitter上我得到了很多不错的反馈和响应。今天我要基于这些评论谈一谈什么时候是可以用!牺牲一匹小马🐴的。
永远不杀小马么？
在上一篇文章里我怂恿你不要用!。有些人可能理解成了"绝不使用，一辈子都不用"。我当时说的意思实际上更偏向于《如果你每次仅仅是为了安抚编译器而加上!，你就杀了一匹小马》。但是显然，如果你的的确确知道自己在干嘛，那匹🐴是可以存活下来的。只是别想都不想，仅仅为了安抚编译器而去加这个!。
所以，没错，在某些情形下使用隐式解析可选类型（implicitly-unwrapped optionals）还是很有益处的，只不过要在正当合理的情况下，在你考虑过后清楚自己为什么这么干的情况下。
什么时候牺牲小马呢？
在Swift中下面的例子里用!是OK的。这些例子也许不仅仅是!的用例，对与小马规则来说，它们还是我能想到的最常见的例外。
1. IBOutlets + 依赖注入（Dependency Injection）
IBOutlets
— 对你们中做DI的人来说，这和依赖注入的属性是一个意思 — 就是一种特殊情况，因为在init方法结束时它们还会是nil（因为它们不会被那么快的初始化），但是它们会很快得到一个值，紧随实例初始化之后（要么通过依赖注入，要么通过XIB-加载机制）。
所以即使它们必须是可选类型（就是在init中不会，而在很短时间之后会被初始化），按照设计，你十分确定它们在余下的代码中不会再是nil了。这就是隐式解析可选类型方便好用的一种情况，因为你知道 在你用它们的时候，它们不会再是nil。
2. UIImage, UIStoryboard, UITableViewCell
UIImage(named: …), UIStoryboard(name:bundle:), UIStoryboard.instanciateViewControllerWithIdentifier:, UITableView.dequeueReusableCellWithIdentifier:forIndexPath:，以及与之类似的东西，用名称(names)和标识符(identifiers)初始化，意味着它们是常量。
对于这些用例，你可能希望当你把名称/标识符打错时你的代码会崩溃，因为这会是一个开发者的错误（由你的bundle里缺少一个图片，或者没有把一个storyboard包含在你的target里，等等情况所引起），你希望在开发阶段的早期就能发现，尽快加以改正。
这也是为什么你要到用一些类似我在enums as constants（常量枚举类型）中讲到的小技巧，以及想要用SwiftGen来避免这些标识符拼写错误引起崩溃的可能性😉。
例如SwiftGen在它的实现过程中实际上是用了UIImage(named: asset.rawValue)!，因为你用的enum实际上是由SwiftGen工具生成的，从而保证了有如此名称的图片确实会存在于你的素材目录（Assets Catalog）中 - 所以根据预先设计，它不会是nil。
在特殊情况下我该牺牲小马么？
这系列文章的第一部分更面向那些Swift的新手，他们总是去强制解析1，因为是Xcode告诉他们要这么做的，或者他们没真正理解可选类型的好处。所以我没讨论上面的那些用例，它们对于我的文章的受众来说有些过于高级。
所以是的，在这些用例中使用!是合理的。但是在我文章第一部分中的建议依然有效：只在你确实知道你为什么这么做，经过思考之后再使用!，别只是去为了安抚编译器。特别强调，如果你是Swift的新手，加!仅仅因为“这些该死的可选类型带着这堆错误提示真烦人”，那这么做就不对了，你要开始屠杀小马了。
欢迎再来看这系列文章的下一部分，是关于map，flatMap，??，可选链以及避免数据不一致的讨论。
- 这里应该插一条“强制解析所有东西” - 我太懒了就没加。
