[swift-evolution] Removing enumerated?

Shawn Erickson shawnce at gmail.com
Fri Feb 3 21:26:57 CST 2017


I use enumerated in many location in my code and have never expected it to
be indexes but a counting of how many times I have looped. It says clearly
what is does on the tin: "Returns a sequence of pairs (n, x), where n
represents a consecutive integer starting at zero, and x represents an
element of the sequence.". I get some new folks have confusion but reading
the docs is always part of learning IMHO.

I would hate to see it removed without strong replacement that is
reasonably readable. I think leveraging zip and the potential range style
is on the edge of being readable but is learnable.

-Shawn
On Fri, Feb 3, 2017 at 4:11 PM Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Feb 3, 2017, at 4:20 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> >
> >
> > on Fri Feb 03 2017, Erica Sadun <erica-AT-ericasadun.com> wrote:
> >
> >>> On Feb 3, 2017, at 2:58 PM, Ben Cohen <ben_cohen at apple.com> wrote:
> >>>
> >>>
> >>>> On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org
> >> <mailto:swift-evolution at swift.org>> wrote:
> >>>>
> >>
> >>>> I believe what people *want* is `indexed` over `enumerated`, and
> consistently for both array and array slices.
> >>>>
> >>>
> >>> I don’t know if that’s true.
> >>>
> >>> Here’s an example (the only use of enumerated) from Alamofire:
> >>>
> >>> let acceptLanguage =
> Locale.preferredLanguages.prefix(6).enumerated().map { index, languageCode
> in
> >>>    let quality = 1.0 - (Double(index) * 0.1)
> >>>    return "\(languageCode);q=\(quality)"
> >>> }.joined(separator: ", ")
> >>>
> >>> Here the intent is a counter, not indices. They just happen to be the
> same. But if they’d used indexed() it would certainly hurt readability,
> albeit midly.
> >>>
> >>> Suppose there wasn’t an enumerate or an indexed, and zipped was the
> standard way of doing it. That might lead to another solution:
> >>>
> >>> let qualities = stride(from: 1.0, to: 0.4, by: -0.1)
> >>> let acceptLanguage = Locale.preferredLanguages.zipped(with:
> qualities).map {
> >>>    languageCode, quality in "\(languageCode);q=\(quality)"
> >>> }.joined(separator: ", ")
> >>>
> >>> The use of stride here feels more what was intended, rather than
> >>> backing into the quality via an “index” value. And avoids any risk
> >>> with indexed of this getting applied incorrectly to slices.
> >>>
> >>
> >> I think enumerated as it stands is an attractive nuisance / moral
> >> hazard. Most of the language learners I interact with miss the point
> >> and the nuance of how it works.
> >>
> >> let list = [0, 1, 2, 3, 4]
> >> let slice = list[2...3]
> >> for (idx, value) in slice.enumerated() {
> >>    print(idx, value)
> >> }
> >>
> >> I think people would not expect 0, 2 / 1, 3. I also don’t think they’d
> >> expect the actual outcome from a dictionary, whether index or
> >> enumeration because there’s no inherent semantic “enumeration” of
> >> dictionary values:
> >>
> >> let dict = [0:"a", 1:"b", 2:"c"]
> >> for (idx, value) in dict.enumerated() {
> >>    print(idx, value)
> >> }
> >>
> >> 0 (2, "c")
> >> 1 (0, "a")
> >> 2 (1, "b")
> >>
> >> I’d like to see enumerated gone and I have a mild preference for
> >> introducing indexed, either under its own name or as a new behavior
> >> for enumerated (although T where T.Iterator.Element is Int)
> >>
> >> 120 gists with “enumerated”, of which a casual scan shows that almost
> >> none of them are actually using it meaningfully. (Take a look.) I
> >> think I did this API right:
> >> https://api.github.com/search/repositories?q=enumerate+language:swift
> >> <https://api.github.com/search/repositories?q=enumerate+language:swift>
> >> and if so, not much in repos.
> >
> > Ben's not arguing that enumerated should stay.  He's just saying that
> > there's no good reason to provide indexed(), and I agree with that.
> >
> > --
> > -Dave
>
> And I think I just argued my way to agreeing with him.
>
> -- E
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170204/f7469c47/attachment.html>


More information about the swift-evolution mailing list