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.
I think the downside is significant. I think the visual relationship of `zip(a, 0…)` with the tuples it produces is pretty important. It also scales well if (when?) it becomes variadic.
Discoverability is a problem, but no more so than with any other top level operator somebody might not be familiar with (Swift has a few of those depending on somebody’s background)
I think the discoverability problem is best addressed by identifying and raising awareness of common use cases for zip rather than just moving it so it appears in autocomplete. When people learn how it can make their code better they will use it.
On Feb 3, 2017, at 3:41 PM, Ben Cohen via swift-evolution <email@example.com> wrote:
swift-evolution mailing list