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().
On Mon, Feb 6, 2017 at 3:14 AM, Ben Cohen via swift-evolution < firstname.lastname@example.org> wrote:
On Feb 5, 2017, at 08:12, Ben Cohen <email@example.com> wrote:
>> On Feb 4, 2017, at 14:43, Dave Abrahams via swift-evolution < > firstname.lastname@example.org> wrote:
>> on Fri Feb 03 2017, Ben Cohen <email@example.com> wrote:
>>>> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via swift-evolution > >>>> <firstname.lastname@example.org> wrote:
>>>> I don't always make zip a method, but when I do, its argument label is
>>> 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
>>> 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"
>> swift-evolution mailing list
swift-evolution mailing list