Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

"In functional programming, “map” must preserve structure (the container shape should stay the same), and “flatMap” must use the same structure throughout, including the return value of the higher order function it takes." I was gonna write the same, completely agree with that. I know Swift is

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

I think we understand each other; we just disagree. If you believe that it makes intuitive sense to talk about “flattening” a sequence of optionals, then the current name perhaps makes sense. If you don’t think so, then the “flatten” name is awkward in this context. I don’t think most Swift

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Looks like I finally have to draw on drawings... (hope the pictures aren’t considered inappropriate content ;-) But after all, it might be the best way to convey my point anyways: I’m not thinking in terms of type names (why should it only be possible to flatten a „Sequence“? Many people

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

“Flatten”, in the context here (flattening a Sequence of Optionals), only makes sense if you consider Optional as a sequence of zero or one elements. While such a sequence does act very similarly to an Optional, the fact remains that Optional is not a Sequence, and is generally not treated as

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Yeah but it seems clear from the return type so I am not sure that much > confusion would really exist. Afaics, there already is lots of confusion — that’s the reason for me to write a sequence of posts in this topic, instead of an Optional ;-) The word „flatten“ is a quite honest

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Yeah but it seems clear from the return type so I am not sure that much confusion would really exist. On Mon, Nov 13, 2017 at 4:57 PM Brent Royal-Gordon wrote: > On Nov 13, 2017, at 10:11 AM, Shawn Erickson via swift-evolution < > swift-evolution@swift.org> wrote: > > On

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 13, 2017, at 10:11 AM, Shawn Erickson via swift-evolution > wrote: > > > On Mon, Nov 13, 2017 at 10:02 AM C. Keith Ray via swift-evolution > > wrote: > > You said "compact" removes nil values, so

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Mon, Nov 13, 2017 at 10:02 AM C. Keith Ray via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 12, 2017, at 10:54 AM, Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Nov 11, 2017, at 8:35 AM, Gwendal Roué via swift-evolution < >

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> • What is your evaluation of the proposal? -1 Code churn, new function name has the same issues as the old one. Benefits small. It is also likely that those suffering with the String collectionifying will have already solved their issues before this update could be introduced. > • Is the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 12, 2017, at 10:54 AM, Paul Cantrell via swift-evolution > wrote: > > >> On Nov 11, 2017, at 8:35 AM, Gwendal Roué via swift-evolution >> wrote: >> >> I'd suggest `compactMap` as an alternative name, should `filterMap` find

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On 8 Nov 2017, at 7:23 AM, John McCall via swift-evolution > wrote: > > Hello, Swift community! > > The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and runs > through November 14th, 2017. The proposal is available here: > >

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 9:29 PM, Paul Cantrell via swift-evolution > wrote: > > The problem in the Doodads example is that the name flatMap is used to > identify two distinct intents: concatenating arrays and filtering nils. One > can argue that those two operations

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 11, 2017, at 8:35 AM, Gwendal Roué via swift-evolution > wrote: > > I'd suggest `compactMap` as an alternative name, should `filterMap` find too > much resistance: I like that name too, though it’s probably my Ruby experience showing. I like the clarity

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Oh right. I guess that makes most of my review beside the point then. Sorry. > Le 11 nov. 2017 à 14:46, BJ Homer > a écrit : > > > >> On Nov 11, 2017, at 9:49 AM, Michel Fortin via swift-evolution >>

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 11, 2017, at 9:49 AM, Michel Fortin via swift-evolution > wrote: > > I think it fits well for arrays. Not sure about optionals. This proposal only suggests changing the one on sequences, and even then, not all of them. Currently, the following exist: //

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> • What is your evaluation of the proposal? One thing to keep in mind is that flatMap is basically the equivalent of optional chaining for non-`self` parameters. let result = character?.hexValue // optional chaining let result = character.flatMap { hexValue($0) } //

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Hello, > • What is your evaluation of the proposal? I'm neutral. My humble contribution is about the name of the method, since many reactions so far have a problem with the proposed filterMap name. I'm found of Ruby's `compact` method. Its role is to filter out nils: [1, 2, nil,

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Am 10.11.2017 um 23:32 schrieb Max Moiseev : > >> extension Collection { >> func filterMap(transform: (Element) -> T, include: (T) -> Bool) -> >> [T] { >> return self.map(transform).filter(include) >> } >> } > > I understand the risk of diverging

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> • What is your evaluation of the proposal? -1 Code churn, new function name has the same issues as the old one. Benefits small. It is also likely that those suffering with the String collectionifying will have already solved their issues before this update could be introduced. > • Is the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 10, 2017, at 4:07 AM, Tino Heth via swift-evolution > wrote: > > >> The “think of optionals as collections” explanation is a good way to help >> people who are confused by the overload. But an even better way would be to >> not have a confusing overload

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> I prefer to think of it this way: it does a mapping, and keeps the results > where the closure did not return nil. In the example given earlier, the > closure returned Optional.some(nil), which is not “nil”. Exactly; therefore, flatMap can even „create“ nil values… Filters in the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 10, 2017, at 4:07 AM, Tino Heth <2...@gmx.de> wrote: > > >> The “think of optionals as collections” explanation is a good way to help >> people who are confused by the overload. But an even better way would be to >> not have a confusing overload in the first place. > With the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md +1 to change it (but the filterMap doesn't' seem perfect neither) • What is your evaluation of the proposal? I'm in favour of renaming that specific variant of flatMap but I'm not 100% that filterMap is

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On 10.11.2017 18:37, BJ Homer via swift-evolution wrote: On Nov 10, 2017, at 5:07 AM, Tino Heth <2...@gmx.de> wrote: A: Well, it does a mapping, and then applies a filter to get rid of nils, I prefer to think of it this way: it does a mapping, and keeps the results where the closure did

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 10, 2017, at 5:07 AM, Tino Heth <2...@gmx.de> wrote: > > A: Well, it does a mapping, and then applies a filter to get rid of nils, I prefer to think of it this way: it does a mapping, and keeps the results where the closure did not return nil. In the example given earlier, the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> The “think of optionals as collections” explanation is a good way to help > people who are confused by the overload. But an even better way would be to > not have a confusing overload in the first place. With the renaming, confusion might strike less often, but with bigger impact (free

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> I’m personally grateful that Swift reminds me that, for example, I need the > question mark in view.gestureRecognizers?.count. It would be maddening if > view.gestureRecognizers.count compiled, and always returned either 0 or 1. > Imagine it! > view.gestureRecognizers.count // returns 0

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

+1 • What is your evaluation of the proposal? I am highly in favor of this proposal. I have seen so many of my peers struggle with custom types, like Result and Observable, that implement a functional flatMap as opposed to the aforementioned flatMap that I've seen create a barrier of learning.

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 1:48 PM, Ben Cohen via swift-evolution > > wrote: > >> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution >> > wrote: >> >> On Nov 9, 2017, at

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 4:01 PM, Paul Cantrell wrote: > > using the same name for both flatMap variants causes the type checker to > miss programmer errors Not to mention, makes it do a lot more work, lengthening compile times (especially when mixed with closure and

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

The idea is that renaming this will nudge people into using map when appropriate. > On Nov 9, 2017, at 1:45 PM, Jose Cheyo Jimenez via swift-evolution > wrote: > > - 1 I agree with Kevin Ballard. > > I think that it would be appropriate to nudge the user to use

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

- 1 I agree with Kevin Ballard. I think that it would be appropriate to nudge the user to use map instead. We already nudge people to use let over var so I think is sensible to do the same for misuses of flatMap when map is sufficient. Thanks! > On Nov 8, 2017, at 10:43 AM, John McCall via

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution > wrote: > > On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution > > wrote: >> >> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> The problem in the Doodads example is that the name flatMap is used to > identify two distinct intents: concatenating arrays and filtering nils. You may have read about my issues with the prefix, but following the same logic of „filtering nils“, the other variant of flatMap just filters out

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution wrote: > > On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote: >> The problem in the Doodads example is that the name flatMap is used to >> identify two distinct intents:

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:> The problem in the Doodads example is that *the name flatMap is used > to identify two distinct intents*: concatenating arrays and filtering > nils. One can argue that those two operations are, in some lofty > abstract

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Nov 9, 2017, at 9:13 AM, Tino Heth via swift-evolution wrote: > > >> Experienced programmers (as experienced as any Swift programmer can be for a >> 4-year-old language) frequently use flatMap when they mean map > When you look at those examples: > What would

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Experienced programmers (as experienced as any Swift programmer can be for a > 4-year-old language) frequently use flatMap when they mean map When you look at those examples: What would stop those programmers to use filterMap in the exact same way, instead of switching to map? A hypothetic

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> What is your evaluation of the proposal? Strong approve. I would happily also accept name variants such as mapFilter — but I’m heartily in favor of _something_ that distinguishes _by name_ flattening sequences vs. filtering nils. > Is the problem being addressed significant enough to

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Wed, Nov 8, 2017, at 02:29 PM, Max Moiseev via swift-evolution wrote:> > >> On Nov 8, 2017, at 12:20 PM, Tino Heth <2...@gmx.de> wrote: >> >> >>> This is a wonderful example! But it’s an argument for a different >>> discussion (of general usefulness of implicit optional promotion). >>>

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 12:20 PM, Tino Heth <2...@gmx.de> wrote: > > >> This is a wonderful example! But it’s an argument for a different discussion >> (of general usefulness of implicit optional promotion). Thanks to the >> optional promotion, what the closure returns is not nil, but instead

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Kevin, I really like your reasoning about avoiding the code churn, and finding a better way to flag something to avoid optional hoisting. I think its better solution to the problem. It also has the added benefit of kicking out to map() and getting a slightly optimised version of the same

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:23 PM, John McCall via swift-evolution > wrote: > > When writing your review, here are some questions you might want to answer in > your review: > > • What is your evaluation of the proposal? -1. I am indifferent on the name, but

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:35 PM, Kevin Ballard via swift-evolution > wrote: > > It's a fairly minor issue, one that really only affects new Swift programmers > anyway rather than all users > I’ve seen enough misuse of flatMap at this point to be confident saying

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 4:23 PM, John McCall via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md > > >

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Am 08.11.2017 um 21:25 schrieb John McCall : > >> My point is: The proposed filterMap isn’t a combination of map and filter at >> all — or can you build it just out of map & filter, like flatMap is >> constructed from map & flatten? > > You can built it out of map and

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 3:20 PM, Tino Heth via swift-evolution > wrote: >> This is a wonderful example! But it’s an argument for a different discussion >> (of general usefulness of implicit optional promotion). Thanks to the >> optional promotion, what the closure

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> This is a wonderful example! But it’s an argument for a different discussion > (of general usefulness of implicit optional promotion). Thanks to the > optional promotion, what the closure returns is not nil, but instead is > .some(nil), and that is not filtered out. My point is: The proposed

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Wed, Nov 8, 2017, at 11:28 AM, Max Moiseev wrote: > > >> On Nov 7, 2017, at 3:34 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:>> >> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift- >> evolution wrote: >>

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 5:23 PM, Tino Heth via swift-evolution > wrote: > > -1 > > I guess breaking existing code will be the show stopper for this proposal — > but I generally think that compatibility is a poor rationale to stop an > improvement, so my personal

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:34 PM, Kevin Ballard via swift-evolution > wrote: > > On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote: >> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md >> >>

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 1:20 PM, Kevin Ballard wrote: > > On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote: >> >>> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution >>> > wrote: >>> >>> On Tue, Nov 7,

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Am 08.11.2017 um 19:23 schrieb Kevin Ballard via swift-evolution > : > > On Tue, Nov 7, 2017, at 05:23 PM, Tino Heth via swift-evolution wrote: >> -1 >> >> I guess breaking existing code will be the show stopper for this proposal — >> but I generally think that

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Tue, Nov 7, 2017, at 05:23 PM, Tino Heth via swift-evolution wrote: > -1 > > I guess breaking existing code will be the show stopper for this > proposal — but I generally think that compatibility is a poor > rationale to stop an improvement, so my personal reasons are > different:> The name is

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote: > >> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:>> >> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift- >> evolution wrote: >>

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Would this attribute not be a form of deprecation? So far, I only encountered deprecation in the context of legacy functionality that will be removed later — but after taking a look in the dictionary, I think the word is actually a good fit (even if there are no plans to remove flatMap). >

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution > wrote: > > On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote: >> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md >> >>

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

-1 I guess breaking existing code will be the show stopper for this proposal — but I generally think that compatibility is a poor rationale to stop an improvement, so my personal reasons are different: The name is just wrong. Just have a look at this simple example extension Int { func

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

• What is your evaluation of the proposal? I approve. This variant of ‘Sequence.flatMap’ is confusing to newcomers, and is inconsistent with the standard term-of-art usage of “flatMap”. People can learn what it means, but it continues to feel awkward. There will be some code churn, but it’s

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md> > • What is your evaluation of the proposal? This proposal is going to cause an insane amount of code churn. The proposal

[swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Hello, Swift community! The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and runs through November 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md