Swift Optionals-不同的解包方式 [英] Swift Optionals - Different ways of unwrapping

问题描述

我会正确处理的:

之间有什么区别

var test: String?
test = "this is an optional string"

if test != nil {
    println("\(test!) IS NOT nil")
} else {
    println("test is nil")
}

和

if let test = test {
    println("\(test) IS NOT nil")
} else {
    println("test is nil")
}

两者在游乐场中输出的结果相同.

Both output the same results in a playground.

我知道隐式解包(在大多数情况下)不被认为是安全的，但是，在这里，我要检查解包之前值是否为nil?

I know implicitly unwrapping is not considered safe (in most cases) but, here I'm checking whether or not the values are nil before unwrapping?

这两种方法都有效吗?是否有不同的方案被认为是更好的选择?

Are both methods valid and are there different scenarios where one is considered the better choice?

推荐答案

这两种方法都有效吗?在不同的情况下，哪种方法被认为是更好的选择?

Are both methods valid, and are there different scenarios where one is considered the better choice?

在每种情况下if-let形式都是更好的选择.发音!的正确方法是我发誓我的程序生命，"因为你在.

The if-let form is the better choice in every case that it can work in. The correct way to pronounce ! is "I swear on my program's life," because you are.

您的示例是琐碎的形式，而在琐碎的形式中，很难看到问题可能如何发生.我 just 对nil进行了测试.可能出什么问题了?但是软件在增长，软件也在变化.您的!= nil检查与人们使用了数十年的C和Java检查相同，并且已经导致程序崩溃了数十年.实际上，错过必需但不是编译器需要的测试非常容易.人们一直在做.

Your example is the trivial form, and in the trivial form it's difficult to see how a problem might occur. I just tested this against nil. What could go wrong? But software grows and software changes. Your != nil check is identical to the C and Java check people have used for decades, and have led to crashing programs for decades. It is in fact very easy to miss a necessary-but-not-compiler-required test. And people do all the time.

重新排列代码并将println移动到函数中时，您还记得也移动过if测试吗?在大型函数中，if测试可能在顶部进行，您是否记得在使用!之前进行了所有这些测试?重构后，这是否仍然成立?修正错误后?对于每个代码更改?

When you rearrange you code and move the println into a function, did you remember to also move the if test? In a large function, where the if tests might be done at the top, did you remember to do all of them before using !? Did that continue to be true after refactoring? After bug fixes? For every code change?

如果忘记使用if-let测试nil，则编译器将阻止您.如果您忘记了使用!= nil进行测试，则崩溃将使您停止；希望，如果您很幸运，可以进行单元测试.如果不是很幸运，可以在现场.

If you forget to test for nil with if-let, then the compiler will stop you. If you forget to test with != nil, a crash will stop you; hopefully, if you're very lucky, in unit testing. If not so lucky, in the field.

也就是说，if-let不是唯一的好机制.您还可以map可选，使用nil合并(??)，可选链接(?.)，这些都是避免bug的出色工具.但是Apple故意选择了!(在Unix中被严重称为"bang").这很危险，只有在其他选项不可行时才应谨慎使用.

That said, if-let is not the only good mechanism. You can also map optionals, use nil coalescing (??), optional chaining (?.), and these are all excellent tools for avoiding bugs. But Apple chose ! (which in Unix is seriously called "bang") on purpose. It is dangerous, and should be used only with great care when other options are unworkable.

最后，如果您完美地编写了代码，则不需要编译器强加的安全性.您可以完全用全局内存在汇编器中编写代码，并避免我们使用抽象的许多成本.但是人类程序员往往会犯很多小错误，这就是为什么你应该避免!.

In the end, if you write code perfectly, then no compiler-imposed safety is required. You could write your code in assembler, entirely with global memory, and avoid many of the costs of abstraction that we use. But human programmers tend to make lots of small mistakes, and that's why you should avoid !.

这篇关于Swift Optionals-不同的解包方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！