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 <[email protected]> wrote:
> > On 7 May 2017, at 10:30, Xiaodi Wu <[email protected]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
