[swift-evolution] [Pitch] Enumerate from offset

[Xiaodi Wu]

I don't see where anything is broken. It sounds like you simply prefer one
style over another, which is fine but cannot justify two features in the
standard library that do the same thing. As you demonstrate, you can easily
write your own method if that's your preference.
On Sun, May 7, 2017 at 04:18 Pavol Vaskovic <pali at pali.sk> wrote:

>
> On 7 May 2017, at 10:30, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Sorry, I'm confused: what is the point of adding a method that does the
> same thing as an existing free function? With one-sided ranges now a part
> of the language, I'd support removal of `enumerated()` with no other
> changes.
>
>
> I’m talking about scenario where you have a chain of sequence operations,
> say:
>
> (1...N).makeIterator().enumerated().lazy.prefix(while: {$0.0 < oneLess}).
> count()
>
> With a free function, you need to break the chain in order to replace
> enumerated with zip:
>
> zip((1...N).makeIterator(), 0...oneLess).lazy.prefix(while: {$0.0 <
> oneLess}).count()
>
> It forces you to rearrange your code into less than ideal order. Free
> function zip works great if you start with it. Not when you need to employ
> it in the middle of the chain.
>
> (1...N).makeIterator().zipped(with: 0...oneLess).lazy.prefix(while: {$0.0
> < oneLess}).count()
>
> Just to be clear, how much change I’m proposing here, in case we remove
> enumerated:
>
> extension Sequence {
>     func zipped<S>(with otherSequence: S) -> Zip2Sequence<Self, S> where S:
> Sequence {
>         return zip (self, otherSequence)
>     }
> }
>
> Best regards
> Pavol Vaskovic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170507/848f5376/attachment.html>