some
。我开始觉得是 SwiftUI 自带的属性,后来经网友提醒发现是 Swift 5.1 的新特性。
some
的用法就是修饰在一个 protocol 前面,默认场景下 protocol 是没有具体类型信息的,可是用 some
修饰后,编译器会让 protocol 的实例类型对外透明。 git
func makeInt() -> Equatable {
return 5
}
let intA = makeInt()
let intB = makeInt()
if intA == intB {
print("equal")
}
复制代码
可是这样写编译器会报错:github
Protocol 'Equatable' can only be used as a generic constraint because it has Self or associated type requirementsswift
Equatable
的协议中的定义和具体类型有关,上面的例子中编译器不知道 makeInt()
返回的具体类型是哪个,所以它不能做为一个函数值返回的类型。不能当作一个类型使用,只能用做泛型约束。app
若是在原有体系下就只能这样作:函数
func makeInt<T: Equatable>() -> T {
return 5 as! T
}
let intA: Int = makeInt()
let intB: Int = makeInt()
if intA == intB {
print("equal")
}
复制代码
在使用泛型约束声明后,在代码调用的时候编译器能够经过类型推断出具体类型是什么,所以就知足了 Equatable
的定义。ui
可是只能用泛型约束声明语法上确实很操蛋。在某些场景下,开发者的函数返回类型是肯定的,可不能够编译器本身推断出具体类型,这样就能够不用泛型约束了呢?spa
想的是真美啊,苹果这就给你实现了: 3d
some
后,返回值的类型对编译器就变成透明的了。在这个值使用的时候编译器能够根据返回值进行类型推断获得具体类型。
那若是我爱的魔力转圈圈,返回值的类型让编译器猜不到呢? code
好吧,编译器是个狼人。 cdn