[swift-evolution] Removing enumerated?

[Dave Abrahams]

on Fri Feb 03 2017, Ben Cohen <swift-evolution at swift.org> wrote:

>> On Feb 2, 2017, at 8:46 PM, Chris Lattner <clattner at 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.

I don't always make zip a method, but when I do, its argument label is
“to:”

-- 
-Dave