做者:Soroush Khanlou,原文连接,原文日期:2016-06-21
译者:Crystal Sun;校对:千叶知风;定稿:CMBpython
在 Python 中,零和 None
,以及空列表、字典和字符串,都有 falsy 值。 若是有 falsy 值,意味着能够它在 if 语句中使用,且可使用 else。 例如,在 Python 中:git
python if []: # will not be evaluated else: # will be evaluated if 0: # will not be evaluated else: # will be evaluated
而在 Swift 中,只有真正的布尔值才能够用在 if 语句里。 nil、空数组,或者其余类型的值出如今在 if 语句中会致使编译失败:github
if Array<String>() { // error: type 'Array<String>' does not conform to protocol 'BooleanType'
Python 和 Swift 都具备一致性,这是好事。在 Swift 里,只有布尔值能够做为 if 语句的判断条件。而在 Python 中,每一个集合类型、整数、nil 值(None
)和布尔均可以做为 if 语句的判断条件。一致性看起来彷佛简单,直到你注意到其余语言有多糟糕。swift
JavaScript 才是真正的垃圾秀。 false
、null
和 undefined
是 falsy,这或多或少还能忍受。可是 0
和 “”
也是 falsy,即便 []
和 {}
是 truthy。 (还有不要尝试解释 JavaScript 的相等行为。数组
虽然我很爱 Objective-C,但它仍然是不具备一致性的语言。 nil
,NO
,false
和 0
是 falsy,而 @ []
,@ {}
,@ 0
和 @NO
是 truthy。 Ruby 在这方面是最好的,只容许 nil
和 false
是 falsy。比起 Ruby,我更喜欢 Swift 的绝对严格。app
一致性虽好,但效用更重要。Swift 的 falsiness 规则虽然好,不过仍是 Python 的规则实用。this
我有两个证据能够证实,为何 Python 的规则比 Swift 的(以及几乎全部其余语言的)更实用。lua
第一个证据是 Rails 的 ActiveSupport
里的 present?
方法。我以前写过 present?
的方法,见这里 。简而言之,可规避 Ruby 运行时惟一不可变的 falsiness。每一个对象均可以规定若是 #present?
.nil
不存在,包括空数组和字符串。能够给对象重写 present?
,若是有自定义集合或空对象。这样会致使你的代码这样:翻译
if myObject.present? { } else { }
重写 Ruby 顽固的 falsiness。 ActiveSupport 只是单纯有用,这也是为何调用 .present?
(和 .blank?
)老是散布在 Rails 的代码库里。code
第二个证据是,Swift 在条件句中处理可选值时是多么尴尬。 留意一下想在代码中检查一个东西是 empty 仍是 nil ,得进行多少操做。而这种检查对我而言很是常见。例如,UITextField 的 text 属性是可选的,若是想检查 text 是否存在,就要进行相似尴尬的操做了:
if let text = textField.text where !text.isEmpty { // we have some text } else { // the string is either empty or nil }
若是这样的代码都让你不以为尴尬,那来尝试颠倒条件。 我会等你哒。 (提示:不能只删除 not 运算符)
很快,你会专门为字符串添加 Optional
方法:
protocol TextContaining { var isEmpty: Bool { get} } extension String: TextContaining { } extension Optional where Wrapped: TextContaining { var isEmpty: Bool { switch self { case let .Some(value): return value.isEmpty case .None: return true } } }
你没必要这样生活! 你值得拥有美好的事情!(好比 Python 的 falsiness)。
不像我提到的其余语言,Swift 是一个高度动态的语言。 容许添加代码来更改编译器的 falsiness 行为。
这是 BooleanType
的文档:
符合布尔型协议的类型能够用于条件语句(if,while,C-style for)和其余逻辑值上下文(例如,guard 语句)。
是的的的的的。
Swift 只有三个类型符合 BooleanType 类型, Bool,DarwinBoolean和ObjCBool。 不建议将此集合扩展为包含表示多个简单布尔值的类型。
Swift 只有三个类型符合 BooleanType 类型, Bool,DarwinBoolean和ObjCBool。 不建议将此集合扩展为包含表示多个简单布尔值的类型。
对不起,Chris Lattner,我要放手一搏了:
extension String: BooleanType { public var boolValue: Bool { return !self.isEmpty } }
完成了!如今咱们能够在条件语句中使用字符串了,代码如期编译成功:
if "" { // this code will not be executed } else { // this code will be executed }
能够对 Dictionary
和 Array
作一样的事情。对可选值来讲,咱们应该检查一下 Wrapped
类型是否遵循 BooleanType
:
extension Optional: BooleanType { public var boolValue: Bool { switch self { case .None: return false case .Some(let wrapped): if let booleanable = wrapped as? BooleanType { return booleanable.boolValue } return true } } }
如今,若是有个拆包的布尔值,实现效果会如你所愿,不会抛出编译报错,不须要在处理奇怪的 optionalBool ?? true
了。
最大的问题是“我应该在生产代码中这样作吗?”。答案是...也许能够吧。若是你在写一个开源库,可能被其余的开发者使用,那绝对不要这样作。若是是在本身写的 App 里添加这样的代码,那不要牵扯任何第三方代码,否则会编译不过的。Swift 是强类型的语言,甚至没法编译 myArray == false
这样的代码。
我以为 Swift 这样作很是棒:建构在一个个小的可组合的块(好比 BooleanType)上,标准库能够在语言中进行自定义(像是 ArrayLiteralConvention 这样的类型都遵循类似的模式)。使人惊讶的是,没有一个“动态”语言容许这种基本语言结构的突变。同时,我不得不决定是否要在全部的地方进行这样的尝试。
本文由 SwiftGG 翻译组翻译,已经得到做者翻译受权,最新文章请访问 http://swift.gg。