原文地址 翻译：DeveloperLx
Swift通常被描述为一个安全的语言。的确，在 swift.org 的 关于 页面中，提到了：
Swift是一种通用的编程语言，采用现代化的方式来构建安全、高性能和软件设计模式进行构建。
以及
安全。 写代码最显而易见的，是应当以安全的方式来表现。未定义的行为是安全的敌人，开发者的错误应当要在产品上线前被捕捉到。选择了安全，就意味着swift会显得很严格，但我们认为这样的清晰长期来看是可以节省时间的。
快速。 Swift旨在代替基于C的语言（C，C++，和Objective-C）。因此，对于大多数的任务，Swift必须在性能上可与之相比。且性能必须是可预测且稳定的，不仅仅是那种在短期内还需要清理的快速。很多的语言都具有着新奇的特性 – 但很少会有快速这一条。
表现力。 表现力。Swift获益于计算机科学几十年的进步，提供了现代的特性开发者所期望的，乐于去使用的语法。但Swift从不止步。我们将监控语言的进步，并拥抱有效的部分，持续地改进使Swift变得更好。
例如，当用到
Optional
类型的对象时，很明显它是如何增强Swift的安全性的。在之前，你是无法知道哪个变量是可以为空，哪个是不可以的。有了这个可为空的信息后，你就必须显式地处理为空时的情形了。当使用这些“nullable”类型时，你可以选择崩溃掉，通常使用一个“
!
”的操作符。“安全”在这里的含义是很明显的。它是你可以选择去解开的“安全带”，但风险要由你自己承担。
然而，在其它的情形下，似乎是缺乏安全性的。让我们来看一个例子。如果我们有一个字典，通过给定的键来获取相应的值，将返回可选的类型：
let person: [String: String] = //... type(of: person["name"]) // =>Optional<String>但我们在数组上做相同的事的时候，得到的却并非是可选的类型：
let users: [User] = //... type(of: users[0]) // => User
为何如此呢？这个数组可能是空的。如果
users
这个数组是空的，那程序就没有选择，只能崩溃。这很难是安全的。我可不想被老板罚钱！
嗯，好吧。Swift有一个开放的开发过程。或许我们可以建议一项改动到
swift evolution
的mailing列表中，然后-
不，这也不行！在
swift-evolution
这个GitHub repo，
“commonly rejected” proposals
提案的页面中，声明了他们是不会接受这样的变化的：
给出了什么？它阐明的原因是，在这种情况下，速度太重要了。但回到上面的关于页面，对于这个语言的描述中，“安全”是被列为“快速”之前的。安全难道不应该比速度更为重要么？
这里有一个基本的争论，解决的要点则在于对“安全”一词的定义。尽管通常对于“安全”的理解是更多或更少的“不要崩溃”，但Swift的核心成员常常会使用相同的词语来表示“永远不会无意识地访问到错误的内存”。
在这种含义之下，Swift的
Array
下标就是“安全”的了。它永远都不会在内存中返回超越数组本身所分配的范围之外的数据。它会在给出你本不应该包含的内存中的句柄前崩溃掉。相同的方式，可选类型避免了现有的整个类型的错误（null解除引用），而这个行为则防止了不同类型错误的存在（缓冲溢出）。
你可以听到Chris Lattner的区分， 在他被ATP采访中的24分39秒 ：
我们说，在社区破坏的成本方面，唯一可以讲得通的方式，是如果我们把它变成为一种安全的编程语言：不是“你不会有bug”，而是在内存方面的“安全”， 同时提供高性能，以及推动编程模型向前发展。
或许“内存安全”是一个比“安全”更好的术语。这个想法是，尽管一些应用的编程者会更喜欢返回可选的类型，而不是捕获超出范围的数组访问，但每个人都可以同意，他们宁愿让程序崩溃，也不要让程序带有包含无效数据的变量，或可能会在缓冲溢出的攻击中被利用的变量继续下去。
尽管第二个权衡（崩溃而不是允许缓冲溢出）可靠看起来很明显，一些语言 并不能 给你这样的包装。在C语言中，访问数据越界会得到未知的行为，意味着任何事都可能发生，具体则依赖于你所使用的编译器的实现。特别是当编程者可以快速被告知它们犯了一个错误的情况下，Swift的团队则表示了，他们认为这是一个可以接受崩溃的地方（一直都是！），而不是返回一个可选类型，并明确地代替返回垃圾内存。
使用这个“安全”的定义也阐明了“不安全”API的设计意图。因为他们直接在内存中“鬼混”（muck about），编程者自己就必须特别小心，来 确保 它永远都不会访问无效的内存。这是非常困难的，甚至专家也会出错。关于这个话题的有趣的读物，请查看 Matt Gallagher的帖子 ：以安全的方式将C连接到Swift。
Swift和核心团队对于“安全”的定义和你可能并不是100%相同的，但他们确实可以防止很多类型的错误，以便像你这样的编程者无需每天都考虑它们。通常，将它们使用的“安全”替换为“内存安全”，可以帮助理解他们的意图。