<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>On Feb 5, 2017, at 16:47, Patrick Pijnappel <<a href="mailto:patrickpijnappel@gmail.com">patrickpijnappel@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Note that <font face="monospace, monospace">zip(a.indices, a)</font> 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.<div><br></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div>Personally I'm in favor of adding <font face="monospace, monospace">indexed()</font><font face="arial, helvetica, sans-serif">.</font></div></div><div class="gmail_extra"><br></div></div></blockquote><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">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) <i>and</i> the collection provided a customized version</span><span style="background-color: rgba(255, 255, 255, 0);">, indexed() would need to use subscripting to return the element given the index it's tracking. </span><span style="background-color: rgba(255, 255, 255, 0);">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.</span></div><span style="background-color: rgba(255, 255, 255, 0);"><br></span><blockquote type="cite"><div dir="ltr"></div></blockquote></div><div><span style="background-color: rgba(255, 255, 255, 0);">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 :)</span></div><br><blockquote type="cite"><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 6, 2017 at 3:14 AM, Ben Cohen via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Feb 5, 2017, at 08:12, Ben Cohen <<a href="mailto:ben_cohen@apple.com">ben_cohen@apple.com</a>> wrote:<br>
<br>
>> On Feb 4, 2017, at 14:43, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>> on Fri Feb 03 2017, Ben Cohen <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>>>> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via swift-evolution<br>
>>>> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>><br>
>>>> I don't always make zip a method, but when I do, its argument label is<br>
>>>> “to:”<br>
>>><br>
>>> Hmm, that doesn’t sound very natural to me.<br>
>>><br>
>>> Then again the problem with “zip(with:)" is it’s already kind of a<br>
>>> term of art for a version that takes a function to combine the two<br>
>>> values.<br>
>>><br>
>>> There’s also the question of how to spell a non-truncating versions<br>
>>> (returning optionals or taking a pad value).<br>
>><br>
>> Is there a use-case for such a zip?<br>
>><br>
><br>
> 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.<br>
><br>
<br>
</span>Gah, accidental double-negation, meant "not OK to silently discard"<br>
<div class="HOEnZb"><div class="h5"><br>
>> --<br>
>> -Dave<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote></body></html>