> On Feb 2, 2017, at 8:46 PM, Chris Lattner <clatt...@nondot.org> wrote: > > It seems that you are leaning towards removing enumerated().
I’m actually kind of conflicted. Replacing enumerated() with indexed() feels replacing one problem for another. Sometimes people want to number things, and might assume indexed() will be zero-based for slices. Adding indexed() while keeping enumerated() seems too much clutter on the API though. Once we have 0… both can be expressed simply with zip, and in my view is zip(a, 0…), zip(a, a.indices), zip(1…, a) just as clear, maybe clearer in some cases as they will encourage code to show intent more (i.e. are you counting or indexing? even when they are the same, it’s better to say which). Encouraging learning about zip will also help introduce people to better ways of expressing other similar-but-different loops. The trouble with zip is it isn’t discoverable – another entry that probably belongs on that list of criteria. Unlike enumerated, users aren’t going to stumble over it. Maybe moving zip to be a method on Sequence rather than a free function would help with this? e.g. something like a.zipped(with: 0…), a.zipped(with: a.indices). The documentation for it could even explicitly mention the counting and index use cases. The main downside is it pushes the order of the lhs/rhs to be self first.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
