I understand the sentiment, but the language has so much sugar over Optional that I wouldn’t be surprised if even seasoned developers didn't know the name of Optional’s cases.
> On 15 Nov 2017, at 22:15, Ben Cohen via swift-evolution > <swift-evolution@swift.org> wrote: > > I continue to favour mapSome, since it’s both literally and figuratively what > it does, but appreciate that exposing the name of the Optional.some case > isn’t to everyone’s taste. > >> On Nov 15, 2017, at 12:55 PM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hello, Swift Community! >> >> The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran >> through yesterday, November 14th, 2017. The proposal is available here: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md> >> >> There was a significant amount of discussion, and people came down with >> reasonable arguments both for and against the proposal. After reviewing >> that feedback, the core team feels that the central question is whether >> Swift benefits from overloading flatMap in this way. There is a reasonable >> argument that an Optional is a sort of container, and therefore it makes >> sense to "flatten" that container into a surrounding container. But Swift >> has resisted applying that interpretation in its library design; for >> example, you cannot directly iterate an Optional or append its contents to >> an Array. In general, we feel that using different operations for working >> with Optionals tends to make code easier to both write and understand, >> especially given the existence of implicit optional promotion, which we >> cannot eliminate or easily suppress based on the context. On reflection, we >> think it was a mistake to use the same name in the first place, and there is >> no better time to fix a mistake than now. >> >> While we accept that this will cause some amount of "code churn" for >> developers when they adopt Swift 5, the required change is a simple rename >> that should be painless to automatically migrate. Of course, sample code on >> the internet will become obsolete, but fix-its will easily update that code >> if pasted into a project, and the samples themselves (once corrected) should >> become clearer and easier to teach after this change, as is generally true >> when overloading is removed. >> >> Accordingly, SE-0187 is accepted, at least as far as not calling the >> operation "flatMap". We are re-opening the review until next Monday, >> November 20th, 2017, in order to have a focused discussion about the new >> name. Names that seemed to gain some traction in the first review include: >> >> - filterMap, which has precedent in existing functional languages, as well >> as some popular Swift libraries, but which some people view as confusing >> >> - compactMap, which builds off the precedent of "compact" in Ruby >> >> But please feel free to suggest a name other than these. >> >> Reviews >> >> Reviews are an important part of the Swift evolution process. All reviews >> should be sent to the swift-evolution mailing list at >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> or, if you would like to keep your feedback private, directly to me as the >> review manager. When replying, please try to keep the proposal link at the >> top of the message: >> >> Proposal link: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md> >> Reply text >> Other replies >> What goes into a review? >> >> The goal of the review process is to improve the proposal under review >> through constructive criticism and, eventually, determine the direction of >> Swift. >> >> When writing your review, here are some questions you might want to answer >> in your review: >> >> • What is your evaluation of the proposal? >> • Is the problem being addressed significant enough to warrant a change >> to Swift? >> • Does this proposal fit well with the feel and direction of Swift? >> • If you have used other languages or libraries with a similar feature, >> how do you feel that this proposal compares to those? >> • How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? >> >> More information about the Swift evolution process is available at: >> >> https://github.com/apple/swift-evolution/blob/master/process.md >> <https://github.com/apple/swift-evolution/blob/master/process.md> >> >> As always, thank you for contributing to the evolution of Swift. >> >> John McCall >> Review Manager >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
