直觉上,这应该是有用的：
extension Collection {
var flatCount: Int {
if self.count == 0 {
return 0
} else if self.first is Collection { // .Iterator.Element: Collection
return self.reduce(0) { (res,elem) -> Int in
res + (elem as! Collection).flatCount // ERROR
}
} else {
return self.reduce(0) { (res,_) in res + 1 }
}
}
}
但是,我们不允许将值转换为具有关联类型的协议类型.
所以我想让Element类型更明确,如下所示：
extension Collection {
var flatCount: Int {
return Self.flatCountH(self)
}
private static final func
flatCountH<C: Collection,D>(_ c: C) -> Int
where Iterator.Element == D,D: Collection {
return c.reduce(0) { (res: Int,elem: D) -> Int in
(res + elem.flatCount) as Int // Ambiguous type
}
}
private static final func flatCountH<C: Collection>(_ c: C) -> Int {
return c.reduce(0) { $0 + $1.flatCount } // Unable to infer closure type
}
}
但这显然是要求太多的类型推断者.
现在我退后一步,决定停止尝试将所有内容都放到一个扩展中：
extension Collection {
var flatCount: Int {
// There's no count on Collection,so...
return self.reduce(0) { (res,_) in res + 1 }
}
}
extension Collection where Iterator.Element: Collection {
var flatCount: Int {
return self.reduce(0) { $0 + $1.flatCount }
}
}
现在这个编译 – 耶！ – 但调度已关闭：$1.flatCount不绑定到第二个递归版本,但总是绑定到第一个普通版本.也就是说,flatCount仅计算第一个嵌套级别.
有没有办法以表达此功能的方式处理类型和/或调度？或者我是以完全迂回的方式(或两个)来解决这个问题？
旁注：在最后一个例子和第一个函数中,我不使用
self.reduce(0) { $0 + 1 }
因为那不编译;在这里,$0是两个匿名参数！我认为这是不必要的令人惊讶的行为,并将a change request发布到Swift bugtracker.
虽然注意到Collection确实有count属性要求,但它只是类型IndexDistance(相关类型),而不是Int.因此,如果可以,您可以将其表达为：
extension Collection {
var flatCount: Indexdistance {
return count
}
}
extension Collection where Iterator.Element: Collection {
var flatCount: Indexdistance {
// compiler error: unable to infer closure type in the current context
// (if you expand it out,it will tell you that it's because
// $1.flatCount is ambiguous)
return self.reduce(0) { $0 + $1.flatCount }
}
}
但是,这会产生一个编译器错误(虽然为什么它不适用于flatCount是Int时,我不知道 – 它们应该是一致编译还是不编译).问题是Swift想要静态调度$1.flatCount – 因此意味着它只能选择一个要调用的扩展(在这种情况下,编译器认为两者同样有效).
静态分派在这里工作的唯一方法是,如果实现是专门针对它们被调用的每个具体类型的Collection.在这种情况下,歧义将被解决,因为编译器将知道实现内部的具体类型,从而知道Iterator.Element.Iterator.Element：Collection是否相应地调度.
但是,目前专业化只是一种优化(由于它有可能在不使用内联来抵消这种额外成本的情况下大幅膨胀代码大小) – 因此不可能保证静态分派对所有情况都有效.
即使$1.flatCount能够动态调度,例如通过protocol witness table(参见this great WWDC talk),基于扩展的类型约束的重载解析需要在运行时进行(以确定调用哪个扩展) ).但是,Swift不会在运行时解决重载(这会很昂贵).相反,重载本身在编译时被解析,然后动态调度允许该重载的实现相对于它被调用的值是多态的(即它可以调度到值的自身的重载实现).
不幸的是,我认为你可能得到的最接近的是为Array编写扩展并使用条件类型转换来迭代嵌套数组：
extension Array {
var flatCount: Int {
var iterator = makeIterator()
if let first = iterator.next() as? [Any] {
// must be an array of arrays – otherwise $1 as! [Any] will crash.
// feel free to add error handling or adding support for heterogeneous arrays
// by doing an O(n) walk.
return iterator.reduce(first.flatCount) { $0 + ($1 as! [Any]).flatCount }
} else {
return count
}
}
}
let arr = [[[[2,3,4]],[3,4,5,6]],[57,89]]
print(arr.flatCount) // 9
虽然注意在下面的注释中作为@MartinR points out,转换为(？/！)[Any]将在大多数情况下创建一个新数组(由于Swift存储具体类型和抽象类型值的方式不同 – 见this Q&A),以上实施不是特别有效.
一个可能的解决方案是使用’伪协议’来声明flatCount属性：
// dummy protocol to prevent conversions of arrays with concrete-typed elements to [Any].
protocol _Array {
var flatCount: Int { get }
}
extension Array : _Array {
var flatCount: Int {
var iterator = makeIterator()
if let first = iterator.next() as? _Array {
// same comment as above,can crash for heterogeneous arrays.
return iterator.reduce(first.flatCount) { $0 + ($1 as! _Array).flatCount }
} else {
return count
}
}
}
这避免了从具体类型元素数组到抽象类型元素的O(n)转换(相反,只为给定数组创建了一个单独的框).
如果我们使用数组对两个实现(在MacBook Pro上的Release版本中)进行粗略的快速基准测试：
let arr = Array(repeating: Array(repeating: Array(repeating: 1,count: 100),count: 1000)
对于对flatCount的10次重复调用,第一次扩展给出了31.7秒的时间.应用于第二种实现的相同基准产生0.93秒.