在 Swift 中同时检查 nil 和 empty 是否安全？答案

【问题标题】：Is checking nil and empty for a set at the same time safe in Swift?在 Swift 中同时检查 nil 和 empty 是否安全？
【发布时间】：2015-10-24 13:39:13
【问题描述】：

我只是想检查一个集合是空还是nil，所以我想知道下面的代码是否安全。（如果 newValue 为 nil 并且系统运行 (newValue!).count 并导致错误是否可以通过？）

if newValue == nil ||  (newValue!).count == 0{
    // Actions here        
}

【问题讨论】：

是的，因为短路是安全的。这是关于数组的类似问题：stackoverflow.com/q/27588964/1630618
@vacawama 谢谢！我想知道是否所有语言都遵守这种规则，因为我知道它在 Java 中是安全的。
如有疑问，请阅读Swift documentation：“与上面的逻辑与运算符一样，逻辑或运算符使用短路求值来考虑其表达式。如果逻辑运算符的左侧OR 表达式为真，不计算右侧，因为它不能改变整个表达式的结果。”
我不会一概而论是否所有人都有这种可能性。 Objective-C 有，Swift 也不确定其他的
如果您发现自己经常这样做，那么您可能使用了 Optional Set，而您应该只使用 Set。如果 nil 和 empty 相同，则根本不需要 Optional。（如果您确实需要这种模式，那么@DepartamentoB 的答案是理想的。）

标签： ios swift null

【解决方案1】：

这是非常安全的，因为它只会在第一个语句为真时执行第二个语句。

最好用：

   guard let newValue = newValue // First unwrap it
       where newValue.count > 0 else { // Then check if the unwrapped value has items
           return // If not we don't continue
   }

   // From this point you don't need to use ? or ! to access newValue anymore

始终尝试在您的 Swift 代码中使用安全模式。对我来说铸造与！是一种代码味道，我总是会尝试用 if let thing = thing 或 guard let thing = thing 语句替换它

【讨论】：

这是 Swift 2.0 的新功能，我认为！使代码更短。
你的意思是只要第一个是假的 :P 否则我们会崩溃
Xcode 7 已经发布了几个星期，我假设您使用的是最新版本。有一种“Swift 做事的方式”，就像你应该使用 Python 的一种方式一样，即使它也允许你以类似 Java 的方式做事。 Swift 是一种非常安全的语言，只要你能做到，你就应该安全地做事。最后一个原因是，以这种方式使用警卫可以让代码的读者更多地了解您想要做什么的意图。 guard 始终用于在您继续执行之前检查某些事情是否为真以及某些选项是否可用。
另一个主要区别是这个答案提前退出，而不是将函数的其余部分包装在 if 中。这通常对可读性非常有利，并使其余代码更简单、更清晰，甚至更短。
我现在使用 guard let，而我曾经使用 if let 在超过 90% 的情况下，很少设置或未设置可选参数会真正触发不同但也正确的行为。

【解决方案2】：

该语句非常好并且保存。

这种编程语言行为的正确术语是short-circuit evaluation。

布尔语句仅在语句可能仍然导致true 和false 之前执行 - 一旦确定结果，它就会完成。

对于&&，这意味着如果一个语句是false，则执行停止。
对于||，这意味着如果一个语句是true，则执行停止。

【讨论】：

谢谢！看起来所有语言都遵守这条规则。

【解决方案3】：

在这种情况下是安全的。因为第一部分使整个陈述成立，所以不需要评估第二部分。

如果可以在其部分之后确定整个条件的结果，则不评估其余部分。这就是条件不应该有任何副作用（改变任何东西）的原因之一

更一般的reading

【讨论】：

根据优化，如果newValue == nil为真，则整个表达式为真。所以我认为(newValue!).count == 0 永远不会运行......但如果你是对的，有没有其他方法可以同时检查这两个条件？
抱歉，因为我一开始就错了，所以对我的答案进行了更改
没关系。你也给了我额外的建议。
一开始我错误地解释了这个例子。我大脑中的解析器失败了 :) @zhongdian 还添加了更一般的阅读