为什么涉及Swift选项的作业类型检查? 例如,
var foo : Int? = 0
foo = foo!
foo和foo!没有相同的类型。您是否需要包装未包装的值以将其分配给可选类型?
答案 0 :(得分:4)
这是选项背后的语法糖的一部分。分配非可选值是如何将其包装在可选类型中。
由于可选项表示存在或不存在值,因此您不必做任何特殊操作来指示除提供值之外的值的存在。例如,在函数中:
func gimmeSomethingMaybe() -> String? {
if arc4random_uniform(10) > 7 {
return "something"
} else {
return nil
}
}
想象一下,如果每次想要从能够返回nil的函数返回实际值时,都必须编写return Optional(value)
。那很快就老了,对吗?可选项是该语言的一个重要特征 - 即使它们实际上是由标准库实现的,但语法糖/自动包装可以防止它使用它们。
编辑:只是为了进一步了解...糖也有助于强化真正的价值不应该是可选的概念。例如:
let one = 1
one? // error (in Swift 1.2, allowed but meaningless in Swift 1.1)
"two"? // error (ditto)
您可以使用Optional(one)
初始化程序创建一个包含真实值的可选项,但它本身几乎没有语义含义,因此您几乎不需要。
选择人物应该在有“神秘”的时候发挥作用。关于值是存在还是不存在 - 也就是说,当程序的一部分是否接收到值(或没有值)时,取决于程序的该部分未知的状态。如果你知道自己有真正的价值,那就没有什么神秘之处......相反,你让未知的人在知道价值的代码和不知道的代码之间的边界发挥作用 - 那个是,将该值移到某处的函数/方法/属性定义。
答案 1 :(得分:0)
在阅读了里克斯特的回答之后,我想出了一个简单的非专业术语答案。对我来说,他的答案的全部要点是
由于可选表示存在或不存在值,因此 不应该做任何特别的事情来表明存在 价值不是提供一个
可选是枚举。其中有2个案例是a或b。
String?
|
An enum with 2 cases
|
a b
| |
Set notSet
| |
any value like "hi" nil
所以当你想要分配给一个可选项时,你可以做任何事情。
假设值为:
nil
代码:
var str : String?
var anotherOptional : String?
str = nil // nil <-- this is like case b
str = "hi" // "hi" <-- this is like case a
str = anotherOptional // nil <-- this is like case c
anotherOptional = "hi again"
str = anotherOptional // "hi again" <-- this is like case c