One reason to favor the class-based approach to type erasure is that the closure-based approach requires more storage if the protocol you're implementing has multiple methods — the closure-based approach requires storage for one closure per method vs. storage for a single reference in the class-based approach.
This argument doesn't really apply to AnyIterator since IteratorProtocol only defines a single method, though. I'm not sure why the standard library prefers the class-based approach.
···
On 05.04.2017 15:22, Pavol Vaskovic via swift-dev wrote:
On Wednesday, 5 April 2017 at 14:56, Pavol Vaskovic wrote:
Thanks Ole! This explanation of type erasure makes total sense. I have overlooked they are generic over different axis.
But I think I have confirmed the performance implications of this design and created [SR-4499] Iterating over elements from existential collections is super slow · Issue #47076 · apple/swift · GitHub to track the issue.
As is, all elements that get vended through this are being created using virtual dispatch on generic protocol - super slow.
If I recall correctly, there is alternative approach to type erasure using closures, but its possible it has similar performance characteristics?Why exactly isn’t `AnyIterator` implemented like this?
public struct AnyIterator<Element> : IteratorProtocol, Sequence {
let _next: () -> Element?
public init<I : IteratorProtocol>(_ base: I) where I.Element == Element {
var _base = base
_next = { return _base.next() }
}
public init(_ next: @escaping () -> Element?) {
_next = next
}
public func next() -> Element? {
return _next()
}It seems to me this is using the same "Methods Constructed in Initializers” pattern I was asking about Re: `_ClosureBasedIterator`.