Oh, absolutely. It's just that the compiler is able to optimize through that under the right circumstances.
When the generator is constructed, wrapped with anyGenerator() and used in the same module, the compiler can in theory inline everything and get rid of any boxes and dynamic dispatch, basically reducing it back to the actual generator. Basically, if the compiler can inline the AnyGenerator construction into the function where it's iterated over, this will work. (But not if you construct the AnyGenerator with a closure. The compiler can't optimize that case (yet).) This might have been one of the reasons the AnyGenerator implementation was changed from Swift 1.2 > 2.0. IIRC it always used a closure for the type erasure before 2.0... Conceptually the same could also work for AnySequence I think. It's just that that is currently too complex for the optimizer to resolve even under ideal circumstances. But this is more of a side-note about the current capabilities and limitations of the compiler. It's much simpler and more reliable to simply avoid AnyGenerator & AnySequence in most cases if their performance is an issue. > On 20 Dec 2015, at 18:11, Donnacha Oisín Kidney <oisin.kid...@gmail.com> > wrote: > > I was under the impression that the biggest speed bump for AnyGenerator was > that it was a class, rather than a struct? All of the generators on the > standard library non-“Any” sequences are structs, for instance. > >> On 20 Dec 2015, at 16:07, Janosch Hildebrand via swift-users >> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >> >> * and can't use generic functions to solve your problem... > - Janosch
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
