[swift-evolution] Removing enumerated?

[Ben Cohen]

> On Feb 5, 2017, at 16:47, Patrick Pijnappel <patrickpijnappel at gmail.com> 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 <swift-evolution at swift.org> wrote:
>> On Feb 5, 2017, at 08:12, Ben Cohen <ben_cohen at apple.com> wrote:
>> 
>> >> On Feb 4, 2017, at 14:43, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> >>
>> >>
>> >> on Fri Feb 03 2017, Ben Cohen <swift-evolution at swift.org> wrote:
>> >>
>> >>>> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via swift-evolution
>> >>>> <swift-evolution at swift.org> 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
>> >> swift-evolution at swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170205/d3e39f51/attachment.html>