> On Feb 5, 2017, at 16:47, Patrick Pijnappel <[email protected]> > wrote: > > Note that zip(a.indices, a) requires advancing the index twice each > iteration, which for non-array collections is not necessarily super trivial. > Considering we're talking about such a low-level operation as iterating > through a collection this might be worth considering. > > Personally I'm in favor of adding indexed(). >
This isn't necessarily as much of a slam-dunk as you might think. Just as index advancement can theoretically be expensive, so can subscripting (though both need to be constant time, the constant factor could be high for either). Unless we made indexed() a protocol customization point rather than an extension (unlikely – we need to keep the number of those under control) and the collection provided a customized version, indexed() would need to use subscripting to return the element given the index it's tracking. Whereas iteration, being a much more limited forward-only API, might be implemented to be more efficient. So it's one hypothetical cost vs another. Alternatively, indexed() could be implemented to use an iterator for the elements part in parallel to the index advancement, in which case it's identical to the zip version. At least with the zip version, it's transparent which strategy is being used. In practice, for any Collection both costs should ideally be kept as small as possible, and so their cost is hopefully not material often enough to be factored into the decision of whether indexed() should exist on Collection, which should be decided on API ergonomics grounds. PS for the standard library collections at least, any benchmarks that find that indexing/subscripting is significantly faster than iteration should be raised as bugs against the std lib/compiler/optimizer depending on where the problem is :) >> On Mon, Feb 6, 2017 at 3:14 AM, Ben Cohen via swift-evolution >> <[email protected]> wrote: >> On Feb 5, 2017, at 08:12, Ben Cohen <[email protected]> wrote: >> >> >> On Feb 4, 2017, at 14:43, Dave Abrahams via swift-evolution >> >> <[email protected]> wrote: >> >> >> >> >> >> on Fri Feb 03 2017, Ben Cohen <[email protected]> wrote: >> >> >> >>>> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via swift-evolution >> >>>> <[email protected]> wrote: >> >>>> >> >>>> I don't always make zip a method, but when I do, its argument label is >> >>>> “to:” >> >>> >> >>> Hmm, that doesn’t sound very natural to me. >> >>> >> >>> Then again the problem with “zip(with:)" is it’s already kind of a >> >>> term of art for a version that takes a function to combine the two >> >>> values. >> >>> >> >>> There’s also the question of how to spell a non-truncating versions >> >>> (returning optionals or taking a pad value). >> >> >> >> Is there a use-case for such a zip? >> >> >> > >> > Whenever it's not OK to not silently discard the elements in the longer >> > list (which can be a correctness trap of zip if you're not careful). Say >> > you're matching up contestants from two groups, but want to give byes to >> > the unmatched contestants in the larger group. Or you're generating a list >> > of positioned racers in a 8-car race, putting in a computer player when >> > you run out of real players. >> > >> >> Gah, accidental double-negation, meant "not OK to silently discard" >> >> >> -- >> >> -Dave >> >> >> >> _______________________________________________ >> >> swift-evolution mailing list >> >> [email protected] >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
