Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Tino Heth via swift-evolution]

> Am 16.11.2017 um 17:02 schrieb BJ Homer via swift-evolution 
> :
> 
> The filterMap operation runs a map that can filter stuff out.
So if map can filter, what’s your opinion on calling the operation mapmap? ;-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Lance Parker via swift-evolution]

I dislike `mapSome` because, to me, it implies it will only pass the non-nil 
values of the sequence to the transformation closure.

`compactMap` isn’t an intuitive name, but I could get used to it. The thing I 
like about it is it could be paired with a `compacted` method that removes nils 
from the Sequence of optionals and returns a Sequence of non-optionals. If 
`compacted` is something that makes sense, then it would be nice if 
`compactMap` was just a merger of `map` and `compacted`. I would prefer to find 
a word other than compact that we could use here but I haven’t thought of one 
yet.

In isolation, I think that `filterMap` is best. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[David Waite via swift-evolution]

> On Nov 15, 2017, at 7:16 PM, Greg Parker via swift-evolution 
>  wrote:
> 
>> 
>> On Nov 15, 2017, at 5:53 PM, John McCall > > wrote:
>> 
>>> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution 
>>> > wrote:


>>> 
>>> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
>>> operation in practice to pull its own weight?

It might be a good criteria, given placeholder ‘xxx’ which is a verb, to think 
of whether for xxxMap or xxxedMap, if xxx/xxxed would be acceptable and 
descriptive terms. We didn’t have flattened() for flatMap, so I think whether 
xxxed()  is present or not is a separate question.

Optional is an adjective, so there may be an ‘xxx’ in the function xxxMap which 
is also an adjective. Not sure how that plays into the naming conventions.
 
>>> "mapSome" is great if you know about Optional.Some but terrible if you 
>>> don't. ("Okay, it maps some elements, but which ones?") 
>>> 
>>> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a 
>>> winner.
>> 
>> mapSome and especially mapNonNil both sound to me like they only map the 
>> non-nil values in the source sequence.
> 
> I thought it did map the non-nil values in the source sequence. Did I 
> misunderstand what the proposed filterMap does? It occurs to me that the 
> proposal does not have a standalone description of the filterMap operation.

It maps all values to optional results, discarding any results which are nil 
and returning just a collection of the unwrapped results - right?

Speaking of which, I don’t feel Sequence.unwrapped() passes muster per my 
stated criteria above.

-DW___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Dave DeLong via swift-evolution]

I agree with Gwendal’s reasoning about the introduction of the term “compact” 
into the API nomenclature. Removing non-existent values is qualitatively 
different than selecting a subset of a sequence based on properties of the 
contained values, and thus merits different terminology. Put a different way: A 
“filter" shouldn’t change the type of the sequence’s element. 

In the case of filterMap(), we have two type transformations going on:  T → U? 
and U? → U. Neither of these is a filter, because neither is an “A → A” 
transformation. So using the term “filter” is incorrect. The first is a map(), 
and the second is technically a reduce(). However, reduce() isn’t commonly used 
in Swift, and the special circumstances surrounding the use of Optional, 
IMO, deserves a special term, given the frequency with which optionals are 
used. “Compact” fits that bill very nicely.

Therefore, a huge +1 from me on the choice of 
“compacted()/compacting()/compactMap()" over “filterMap” or whatever.

Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Kevin Nattinger via swift-evolution]

As far as the Sequence overloads: I really, really think we should go a step 
beyond renaming and separate the functions into the underlying operations. 
FlatMap has three separate and orthogonal effects, so it should be split into 
three functions—flatten, map, and dropNil. Map already exists, obviously, but 
flatten and dropNil (or compact[ed], as I've seen suggested) are independently 
useful—I've used `.flatMap { $0 }` several times, and I've written my own 
`flatten` because I didn't actually realize there was a separate overload for 
that (I don't want to sound rude to the Apple devs who decided on that, but… 
why on earth was an already confusing name overloaded with unrelated 
functionality instead of using the term of art?). 

For Optional, I suggest mapValue.

> On Nov 16, 2017, at 8:11 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
> I like `mapSome`:
> 
> * `mapSome` uses conventional Swift terminology. 
> * It makes the outcome and expectations clear. 
> * As a bonus, it combines the English meaning of "some" ("map across some of 
> these items", as in creating a filtered result) and the `Optional` case name. 
> 
> In response to John's "mapSome and especially mapNonNil both sound to me like 
> they only map the non-nil values in the source sequence.", I'd respond that   
> the mode of action is:
> 
> 1. apply the function
> 2. retrieve `some` cases 
> 
> Selecting `mapSome` reflects those two stages. There is, however, Kevin's 
> (sound) point against that it "sounds like it takes a sequence of optionals 
> and only modifies the non-nil values", but I still like it.  Some of the 
> suggestions built around unwrapping address John's concern, for example 
> `mapUnwrapped` but fail to distinguish between the `some` and `nil` cases, 
> suggesting perhaps a catastrophic outcome for nil values.
> 
> I could live with many of the other names but I dislike `compact` (it has no 
> precedent, sets an expectation of the implementation which may not match 
> reality). Similarly `mapReduce` or `mapReducing` (which I prefer to 
> `reduceMap`) may overburden the expectation of the existing `reduce`, where a 
> user thinks prior results feed into the output, which they don't.  I 
> moderately like `mapSelective` (over `selectiveMap`) but I like it less than 
> `filterMap`, `mapFiltering`, or `mapFiltered` and `mapSome`, all of which use 
> Swift terms of art in their naming. (Also note Gwendal's finding that as a 
> term of art, it has "a different signature, and a different meaning" in 
> RxSwift.)
> 
> Summary:
> 
> * I like `mapSome`
> * I'm fine with a `filter` variation, of which I prefer `mapFiltered`
> 
> -- E, former supporter of `filterMap` before `mapSome` entered her awareness
> 
> 
>> On Nov 15, 2017, at 2:15 PM, Ben Cohen via swift-evolution 
>> > 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 
>>> > 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
>>>  
>>> 
>>> 
>>> 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 

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Brandon Williams via swift-evolution]

I’ll put my vote in for `filterMap`!

I’d like to call out some fun properties and generalizations that
`filterMap` has that might give a little more credence to why it should be
called this.

There is a very natural way of bridging the worlds of optionals and
booleans.   In fact, considering that `Bool` is the unique type with two
elements, we could even define `typealias Bool = Void?`, where `Void()` is
true and `nil` is false! Though I am definitely not advocating that!

Given that perspective, there is then also a natural way of lifting
predicates `(A) -> Bool` to the world of functions that `filterMap`
understands:

```
func optionalBool(_ p: @escaping (A) -> Bool) -> (A) -> A? {
  return { p($0) ? .some($0) : nil }
}
```

Given such a function, then `filter` on arrays is nothing but
`filterMap(optionalBool(p))`!

The really exciting part is then to take note that the highly contested and
dreaded `Either` is just a generalization of `Optional`, in that
we model the absence of `B` by providing a value of type `A`. Given that
observation, what does the filter/filterMap story look like for `Either`s?
Why that’s none other than `partition` and `partitionMap`! These are
functions that allow you to partition an array into two subsets. The first
one doesn’t change the wrapped value of the array (much like `filter`) but
the second allows providing an additional mapping function. Here’s how they
might look:

```
func _partitionMap(_ p: @escaping (Element) -> Either) ->
(left: [A], right: [B]) {
  var result = (left: [A](), right: [B]())
  for x in self {
switch p(x) {
case let .left(a):
  result.left.append(a)
case let .right(b):
  result.right.append(b)
}
  }
  return result
}

func _partition(_ p: @escaping (Element) -> Bool) -> (`true`: Array,
`false`: Array) {
  // Can easily define `_partition` in terms of `_partitionMap`!
  return _partitionMap(eitherBool(p))
}
```

The things that are nice about this:

* Builds on a few foundational, atomic ideas.
* Shows that there are future generalizations that we might not even be
thinking about right now
* Allows one to see the shadows of simpler constructions (e.g.
filter/partition) from the more complex constructions (e.g.
filterMap/partitionMap)

I will conclude that I 100% am not advocating for us to bring in `Either`
and `optionalBool` and `eitherBool` and all that wildness. I simply want to
show that there are some wonderful ideas lurking behind these names, and so
it’d be nice to not hide them with overly specific and overly descriptive
names.

If anyone wants to play with these functions I have put them in a gist:

https://gist.github.com/mbrandonw/7aab415312379022e60f3a9a107b6792




On Nov 15, 2017, at 12:55 PM, John McCall via swift-evolution <
> 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
>
>
> 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

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Erica Sadun via swift-evolution]

I like `mapSome`:

* `mapSome` uses conventional Swift terminology. 
* It makes the outcome and expectations clear. 
* As a bonus, it combines the English meaning of "some" ("map across some of 
these items", as in creating a filtered result) and the `Optional` case name. 

In response to John's "mapSome and especially mapNonNil both sound to me like 
they only map the non-nil values in the source sequence.", I'd respond that   
the mode of action is:

1. apply the function
2. retrieve `some` cases 

Selecting `mapSome` reflects those two stages. There is, however, Kevin's 
(sound) point against that it "sounds like it takes a sequence of optionals and 
only modifies the non-nil values", but I still like it.  Some of the 
suggestions built around unwrapping address John's concern, for example 
`mapUnwrapped` but fail to distinguish between the `some` and `nil` cases, 
suggesting perhaps a catastrophic outcome for nil values.

I could live with many of the other names but I dislike `compact` (it has no 
precedent, sets an expectation of the implementation which may not match 
reality). Similarly `mapReduce` or `mapReducing` (which I prefer to 
`reduceMap`) may overburden the expectation of the existing `reduce`, where a 
user thinks prior results feed into the output, which they don't.  I moderately 
like `mapSelective` (over `selectiveMap`) but I like it less than `filterMap`, 
`mapFiltering`, or `mapFiltered` and `mapSome`, all of which use Swift terms of 
art in their naming. (Also note Gwendal's finding that as a term of art, it has 
"a different signature, and a different meaning" in RxSwift.)

Summary:

* I like `mapSome`
* I'm fine with a `filter` variation, of which I prefer `mapFiltered`

-- E, former supporter of `filterMap` before `mapSome` entered her awareness


> On Nov 15, 2017, at 2:15 PM, Ben Cohen via swift-evolution 
>  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 
>> > 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
>>  
>> 
>> 
>> 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
>> 
>> 

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[BJ Homer via swift-evolution]

> On Nov 15, 2017, at 11:07 PM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> 
>> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution 
>> > a écrit :
>> 
>> My opinion is that filterMap is the right choice of name.
>> 
>> I'm completely biased, given that I already have a Swift library that uses 
>> filterMap, in exactly this context, for a Reactive Programming library:
>> 
>>  
>> https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3
>>  
>> 
> 
> Another popular Reactive Programming Library uses filterMap with a different 
> signature, and a different meaning: 
> https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32
>  
> 
> 
> There are already different interpretations on "filter" in "filterMap" in the 
> wild.
> 
> Gwendal Roué
> 

This library is using filterMap in exactly the same way proposed, except that 
they use a custom result type instead of Optional. So yes, it has a different 
signature, but I don’t think it has a different meaning. It’s still running a 
map operation that may filter some values out.

-BJ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[BJ Homer via swift-evolution]

> On Nov 16, 2017, at 2:52 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
>> The optional itself will stand for the boolean needed by the filtering 
>> operation.
> 
> What I meant here is that "filterMap" can only click in a developer's mind if 
> the the developer uses Optional as a Bool. When the closure returns nil, that 
> nil stands for false in the filtering operation. When the closure returns a 
> `some`, that some stands for true in the filtering operation.
> 
> Put in another way: to properly explain "filterMap" to someone who already 
> knows "filter", then you have to explain that optionals are used as booleans.

I disagree that you have to view Optionals as Booleans to understand filterMap 
as proposed. Optionals naturally represent the idea of either a value, or 
nothing. The filterMap operation runs a map that can filter stuff out. If you 
filter something out, you end up with “nothing”, which is exactly what 
returning nil means. So when I use filterMap, I map all the things I want to 
let through, and I filter the rest out by letting nothing through.

-BJ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[BJ Homer via swift-evolution]

mapSome is easy to misunderstand; the naïve reading suggests that only some of 
the source elements will be mapped, and doesn’t specify which ones. Even if the 
reader correctly intuits that it refers to Optional.some, they may incorrectly 
believe that it only maps the non-nil elements in the source sequence. I don’t 
think this is the right solution.

mapAndUnwrap is accurate to the behavior, but gives an ambiguous impression of 
what will happen to the nil values. I would worry that returning nil would 
cause a crash due to a force-unwrap. I don’t want the nil values unwrapped; I 
want them dropped from the result entirely, so calling it “unwrap” feels scary.

I really think we need something that mentions that the purpose of using this 
operation is to drop empty values.

-BJ

> On Nov 16, 2017, at 8:40 AM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> I so far am most in favor of mapSome out of the names I have seen followed by 
> mapAndUnwrap (however the later is growing on me).
> 
> 
> To me the most important thing is when reading code that it is quick to 
> understand generally what is going on followed by discoverability of a new 
> comer. I think both of these are fairly clear on a quick read while a lot of 
> the others are heavily overloaded terms. I also they sufficiently 
> discoverable / learnable ... also mor so then some of the other overload 
> terms.
> 
> -Shawn
> 
> 
> On Wed, Nov 15, 2017 at 10:07 PM Gwendal Roué via swift-evolution 
> > wrote:
>> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution 
>> > a écrit :
>> 
>> My opinion is that filterMap is the right choice of name.
>> 
>> I'm completely biased, given that I already have a Swift library that uses 
>> filterMap, in exactly this context, for a Reactive Programming library:
>> 
>>  
>> https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3
>>  
>> 
> 
> 
> Another popular Reactive Programming Library uses filterMap with a different 
> signature, and a different meaning: 
> https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32
>  
> 
> 
> There are already different interpretations on "filter" in "filterMap" in the 
> wild.
> 
> Gwendal Roué
> 
> ___
> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Shawn Erickson via swift-evolution]

I so far am most in favor of mapSome out of the names I have seen followed
by mapAndUnwrap (however the later is growing on me).


To me the most important thing is when reading code that it is quick to
understand generally what is going on followed by discoverability of a new
comer. I think both of these are fairly clear on a quick read while a lot
of the others are heavily overloaded terms. I also they sufficiently
discoverable / learnable ... also mor so then some of the other overload
terms.

-Shawn


On Wed, Nov 15, 2017 at 10:07 PM Gwendal Roué via swift-evolution <
swift-evolution@swift.org> wrote:

> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> My opinion is that filterMap is the right choice of name.
>
> I'm completely biased, given that I already have a Swift library that uses
> filterMap, in exactly this context, for a Reactive Programming library:
>
>
> https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3
>
>
> Another popular Reactive Programming Library uses filterMap with a
> different signature, and a different meaning:
> https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32
>
> There are already different interpretations on "filter" in "filterMap" in
> the wild.
>
> Gwendal Roué
>
> ___
> 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

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Benjamin G via swift-evolution]

I like mapAndUnwrap , but just for the record I'd like to add
"mapThenUnwrap"

I'm not a native english, but i think "and" doesn't convey as much meaning
relative to the order of the operation as "then".

As a sidenote, if we go this road I think flatMap should also be the object
of a renaming proposal. we would have
map,
mapThenFlatten and
mapThenUnwrap.

It doesn't look as functional style programming as flatMap and filterMap ,
but it's IMHO incredibly clearer. I remember being very puzzled by flatMap
the first time is discovered it and its type signature, making me think it
was "a different kind" of map, instead of a map plus something more in the
end of the process.


On Thu, Nov 16, 2017 at 11:23 AM, Jean-Daniel via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>
> Here's a variety of possible new names, in descending order of personal
> preference:
>
> mapUnwrappingSome
> mapAndUnwrap  // Thanks Nevin, this is surprisingly clear.
> mapUnwrapSome
> mapUnwrapIfSome
> mapSome   // For these last three, it's unclear when nil elements
> are dropped. Before or after the map?
> mapNonNil
> mapStrippingNil
>
>
> An other explicit alternative
>
> mapIfNotNil()
>
>
>
> ___
> 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

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Jean-Daniel via swift-evolution]

> 
> Here's a variety of possible new names, in descending order of personal 
> preference:
> 
> mapUnwrappingSome
> mapAndUnwrap  // Thanks Nevin, this is surprisingly clear.
> mapUnwrapSome
> mapUnwrapIfSome
> mapSome   // For these last three, it's unclear when nil elements are 
> dropped. Before or after the map?
> mapNonNil
> mapStrippingNil
> 

An other explicit alternative

mapIfNotNil()


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Gwendal Roué via swift-evolution]

> Le 16 nov. 2017 à 11:06, Brent Royal-Gordon via swift-evolution 
>  a écrit :
> 
>> On Nov 15, 2017, at 4:36 PM, Greg Parker via swift-evolution 
>> > wrote:
>> 
>> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
>> operation in practice to pull its own weight?
> 
> Lines containing code like `flatMap { $0 }`—which could be compacting 
> optionals or flattening nested sequences—appear 89 times in the source 
> compatibility suite. (I happen to have it on my hard drive right now.)
> 
> My main concern about adding a compacting method is…well, am I missing a 
> better implementation than the slightly gross one I cooked up in a playground 
> just now?
> 
>   protocol _OptionalProtocol {
>   associatedtype _Wrapped
>   var _optional: _Wrapped? { get }
>   }


Welcome to the club :-) 
https://github.com/search?q=OptionalProtocol+language%3Aswift=Code=✓

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Brent Royal-Gordon via swift-evolution]

> On Nov 15, 2017, at 4:36 PM, Greg Parker via swift-evolution 
>  wrote:
> 
> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
> operation in practice to pull its own weight?

Lines containing code like `flatMap { $0 }`—which could be compacting optionals 
or flattening nested sequences—appear 89 times in the source compatibility 
suite. (I happen to have it on my hard drive right now.)

My main concern about adding a compacting method is…well, am I missing a better 
implementation than the slightly gross one I cooked up in a playground just now?

protocol _OptionalProtocol {
associatedtype _Wrapped
var _optional: _Wrapped? { get }
}

extension Optional: _OptionalProtocol {
var _optional: Wrapped? {
return self
}
}

extension Sequence where Element: _OptionalProtocol {
func compacted() -> [Element._Wrapped] {
return flatMap { $0._optional }
}
}

let a = [1, nil, 2]
a.compacted()   // [1, 2]


-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Gwendal Roué via swift-evolution]

> The optional itself will stand for the boolean needed by the filtering 
> operation.

What I meant here is that "filterMap" can only click in a developer's mind if 
the the developer uses Optional as a Bool. When the closure returns nil, that 
nil stands for false in the filtering operation. When the closure returns a 
`some`, that some stands for true in the filtering operation.

Put in another way: to properly explain "filterMap" to someone who already 
knows "filter", then you have to explain that optionals are used as booleans.

Now if one has to answer the canonical question "Does this proposal fit well 
with the feel and direction of Swift?", then one has to admit that the 
confusion of Optional with Bool has been rejected a long time ago as not 
fitting well with the direction of Swift.

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Gwendal Roué via swift-evolution]

Yes, you are right. I was too fast.

I've been thinking why filterMap has such a traction in the community, despite 
the fact that this precise "filter" is a tiny subset of the "filter" generally 
used by the language.

I think "filterMap" clicks well in many readers because of this trend of 
thought:

1. I need to transform some values and only keep some of them. But I don't want 
to use `seq.filter { ... }.map { ... }` or `seq.map { ... }.filter { ... }`. I 
don't even want to think about the ordering of the filter and mapping 
operations: that's not interesting. I want a versatile filter+map operation 
that I'll call "filterMap".
2. Now I need a closure that returns a two-state value: either (in+value), or 
(out).
3. Which existing Swift type fits such a requirement? Optional, of course. The 
optional itself will stand for the boolean needed by the filtering operation. 
The wrapped value will give the mapped value. Pretty efficient.

This trend of thought starts from an actual need (I don't know how to call it) 
and builds a rationale for it to use the words "filter", "map", and the 
Optional type. It uses optionals as booleans, which is a venial sin. It happens 
to build a 100% compatible replacement for the old "flatMap".

The "compact" trend of thought introduces a new operation which filter out 
nils. It happens to build a 100% compatible replacement for the old "flatMap".

The previous trend of thought (flatMap) did consider optionals as collections. 
It happens to confuse people, and has been rejected.

The three ways of thinking build the same function. I've been pushing "compact" 
has a way to better explore the subject. But I really don't know how the Swift 
community prefers to wire the developer's brains.

Gwendal



> Le 16 nov. 2017 à 09:12, Anders Ha  a écrit :
> 
> It does not use `Optional`, but it is semantically equivalent to `filterMap` 
> in CwlSignal and ReactiveSwift, and the `filterMap` proposed for `Sequence` 
> (but in the time domain instead).
> 
> 
> 
> Regards,
> Anders
> 
> 
> 
>> On 16 Nov 2017, at 2:07 PM, Gwendal Roué via swift-evolution 
>> > wrote:
>> 
>> 
>>> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution 
>>> > a écrit :
>>> 
>>> My opinion is that filterMap is the right choice of name.
>>> 
>>> I'm completely biased, given that I already have a Swift library that uses 
>>> filterMap, in exactly this context, for a Reactive Programming library:
>>> 
>>> 
>>> https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3
>>>  
>>> 
>> 
>> Another popular Reactive Programming Library uses filterMap with a different 
>> signature, and a different meaning: 
>> https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32
>>  
>> 
>> 
>> There are already different interpretations on "filter" in "filterMap" in 
>> the wild.
>> 
>> Gwendal Roué
>> 
>> ___
>> 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

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Anders Ha via swift-evolution]

It does not use `Optional`, but it is semantically equivalent to `filterMap` in 
CwlSignal and ReactiveSwift, and the `filterMap` proposed for `Sequence` (but 
in the time domain instead).



Regards,
Anders



> On 16 Nov 2017, at 2:07 PM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> 
>> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution 
>> > a écrit :
>> 
>> My opinion is that filterMap is the right choice of name.
>> 
>> I'm completely biased, given that I already have a Swift library that uses 
>> filterMap, in exactly this context, for a Reactive Programming library:
>> 
>>  
>> https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3
>>  
>> 
> 
> Another popular Reactive Programming Library uses filterMap with a different 
> signature, and a different meaning: 
> https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32
>  
> 
> 
> There are already different interpretations on "filter" in "filterMap" in the 
> wild.
> 
> Gwendal Roué
> 
> ___
> 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

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Gwendal Roué via swift-evolution]

> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution 
>  a écrit :
> 
> My opinion is that filterMap is the right choice of name.
> 
> I'm completely biased, given that I already have a Swift library that uses 
> filterMap, in exactly this context, for a Reactive Programming library:
> 
>   
> https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3
>  
> 

Another popular Reactive Programming Library uses filterMap with a different 
signature, and a different meaning: 
https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32

There are already different interpretations on "filter" in "filterMap" in the 
wild.

Gwendal Roué

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Gwendal Roué via swift-evolution]

> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution 
>  a écrit :
> 
> On the topic of a method that "compacts" without also mapping... I think this 
> encourages poor designs that should be using lazy transformations instead of 
> aggregate processing. There is almost always a way around a bare flatten. The 
> obvious quirkiness of `filterMap { $0 }` (or whatever the name ends up being) 
> should be seen as a nudge to re-think the algorithm leading up to that point.

I can hear the argument, but it errs in the side of premature optimization. 
Besides, seq.lazy.compacted() still has a meaning.

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Matt Gallagher via swift-evolution]

My opinion is that filterMap is the right choice of name.

I'm completely biased, given that I already have a Swift library that uses 
filterMap, in exactly this context, for a Reactive Programming library:


https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3

Obviously, I went through the thought process, looked at other libraries and 
thought it was the best name.

On the topic of a method that "compacts" without also mapping... I think this 
encourages poor designs that should be using lazy transformations instead of 
aggregate processing. There is almost always a way around a bare flatten. The 
obvious quirkiness of `filterMap { $0 }` (or whatever the name ends up being) 
should be seen as a nudge to re-think the algorithm leading up to that point.

Cheers,
Matt Gallagher.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Dylan Brown via swift-evolution]

I'll argue in favor of names which include the term "some".

"The Optional type is an enumeration with two cases. Optional.none is
equivalent to the nil literal. Optional.some(Wrapped) stores a wrapped
value." (https://developer.apple.com/documentation/swift/optional)

let things = ["apple", nil, "cat", "dog"]

print( things )
print( things.flatMap {$0} )

// Equivalently: apply map, filter for non-nil, and apply force unwrap.
func transform(x: Any?) -> Any? {return x}
print( things.map(transform).filter { $0 != nil }.map { $0! } )

for x in things {
  switch x {
  case .some:
print(x!)
  case .none:
break
  }
}

[Optional("apple"), nil, Optional("cat"), Optional("dog")]
> ["apple", "cat", "dog"]
> ["apple", "cat", "dog"]
> apple
> cat
> dog


Here's a variety of possible new names, in descending order of personal
preference:

mapUnwrappingSome
mapAndUnwrap  // Thanks Nevin, this is surprisingly clear.
mapUnwrapSome
mapUnwrapIfSome
mapSome   // For these last three, it's unclear when nil elements
are dropped. Before or after the map?
mapNonNil
mapStrippingNil

I'm opposed to filterMap. Combining the names of two commonly used methods
for this less frequent operation seems likely to cause as much confusion as
flatMap.
I'm opposed to compactMap. There are two English meanings of "compact", and
my initial thought was about enforcement of some kind of contract.
I think mapUnwrappingSome is explicit, puts clarity > brevity, and
maintains naming consistency within Swift. If the enumeration cases .some
and .none are taught along with Optionals, then this name is clear.

That's my 2-cents as a relatively inexperienced user.
-Dylan

On Wed, Nov 15, 2017 at 6:48 PM, Nevin Brackett-Rozinsky via
swift-evolution  wrote:

> On Wed, Nov 15, 2017 at 8:05 PM, Wallacy via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> “unwrappingMap”(or some variations using unwrap).
>>
>
>  I’d like to propose “mapAndUnwrap”.
>
> It does what it says on the tin: map a sequence (into an optional type),
> then unwrap the values which exist.
>
> Nevin
>
> ___
> 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

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Jon Shier via swift-evolution]

Given the existence of filter already, I submit that filterMap is 
somewhat overloaded and users would expect that, like flatMap, it would map 
over all elements and then filter based on some predicate. While that’s awkward 
to express and likely isn’t useful enough to be in the standard library, to 
have it just handle nils would seem unexpected to anyone who hadn’t read the 
signature when finding it in the autocomplete list or reading in documentation. 
That why I like compact. It’s currently unused in Swift, so it can be given 
whatever meaning we want, and it coincides with Ruby’s use of it, meaning 
there’s at least some precedent for using it to remove nils.



Jon

> On Nov 15, 2017, at 9:58 PM, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Nov 15, 2017, at 9:16 PM, Greg Parker > > wrote:
>> 
>> 
>>> On Nov 15, 2017, at 5:53 PM, John McCall >> > wrote:
>>> 
 On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution 
 > wrote:
 
> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
> > wrote:
> 
>> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
>> > wrote:
>> 
>> Odd… exactly that is the reason why I think filterMap is the worst 
>> choice:
>> 
>> Both are established terms of art, but one has a meaning that doesn’t 
>> fit to the operation.
>> Applying filter can remove elements, but it can never change types (I 
>> feel kind of silly to repeat this over and over, but so far, nobody took 
>> the time to falsify this).
> 
> The concern about filter changing types is only relevant if you think of 
> the filter applying to the result of the map, instead of being a part of 
> the filterMap operation itself (an operation that is distinct from map).
> 
> Let’s imagine that we had this instead:
> 
> enum SelectiveMapResult {
> case use(T)
> case ignore
> }
> 
> extension Sequence {
> func selectiveMap(_ selectiveTransform: 
> (Element)->SelectiveMapResult) -> [T]
> }
> 
> let actualNumbers =
> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
> (x)->SelectiveMapResult in
> if let value = Int(x) { return .use(value) }
> else { return .ignore }
> })
> 
> actualNumbers == [1, 2, 5]
> 
> The “selective” part of this operation doesn’t feel like it’s changing 
> the type of the result, because SelectiveMapResult is easily understood 
> to not be part of the mapping transformation; it just exists to tell us 
> whether we should use the result of that particular transformation. 
> Likewise, I don’t feel like the optional in filterMap is part of the 
> mapping operation; it’s just serving the same role as SelectiveMapResult. 
> (It should be obvious that SelectiveMapResult is just Optional with 
> another name here.)
 
 "selectiveMap" feels better in part due to grammar. "map" is obviously the 
 verb and "selective" is obviously a modification of "map". "selectiveMap" 
 is therefore performing some sort of special map operation. 
 
 "filterMap" feels bad for the same reason that "selectMap" would feel 
 worse than "selectiveMap". "filter" and "map" are both verbs in this 
 context. Grammatically the analogue to "selectiveMap" would be 
 "filteredMap" or "filteringMap". 
 
 But even then "filteredMap" or "filteringMap" is insufficient to describe 
 the operation. You additionally need to know that the "filter" here is not 
 ordinary "filter", but instead the special case "filter { $0 != nil }".
 
 
> The name filterMap focuses on removing the ignored values, as does 
> compactMap. The name selectiveMap focuses on retaining the non-ignored 
> values. I’m not sure whether focusing on the positive or negative aspects 
> is clearer here. I don’t particularly like the name compactMap, simply 
> because I don’t have a lot of experience with languages that use 
> “compact” to mean “drop the nil values”, and without that experience it 
> doesn’t seem intuitive. I think filterMap is better. But if we introduced 
> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
 
 Swift doesn't use "filter" to mean "drop the nil values" either. 
 
 
 "compactMap" is okay if "compact" is added. Is "compact" a common enough 
 operation in practice to pull its own weight?
 
 "mapSome" is great if you know about Optional.Some but terrible if you 
 don't. ("Okay, it maps some elements, but which ones?") 
 
 

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[John McCall via swift-evolution]

> On Nov 15, 2017, at 9:16 PM, Greg Parker  wrote:
> 
> 
>> On Nov 15, 2017, at 5:53 PM, John McCall > > wrote:
>> 
>>> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution 
>>> > wrote:
>>> 
 On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
 > wrote:
 
> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
> > wrote:
> 
> Odd… exactly that is the reason why I think filterMap is the worst choice:
> 
> Both are established terms of art, but one has a meaning that doesn’t fit 
> to the operation.
> Applying filter can remove elements, but it can never change types (I 
> feel kind of silly to repeat this over and over, but so far, nobody took 
> the time to falsify this).
 
 The concern about filter changing types is only relevant if you think of 
 the filter applying to the result of the map, instead of being a part of 
 the filterMap operation itself (an operation that is distinct from map).
 
 Let’s imagine that we had this instead:
 
 enum SelectiveMapResult {
 case use(T)
 case ignore
 }
 
 extension Sequence {
 func selectiveMap(_ selectiveTransform: 
 (Element)->SelectiveMapResult) -> [T]
 }
 
 let actualNumbers =
 ["1", "2", "apple", "banana", "5"].selectiveMap({ 
 (x)->SelectiveMapResult in
 if let value = Int(x) { return .use(value) }
 else { return .ignore }
 })
 
 actualNumbers == [1, 2, 5]
 
 The “selective” part of this operation doesn’t feel like it’s changing the 
 type of the result, because SelectiveMapResult is easily understood to not 
 be part of the mapping transformation; it just exists to tell us whether 
 we should use the result of that particular transformation. Likewise, I 
 don’t feel like the optional in filterMap is part of the mapping 
 operation; it’s just serving the same role as SelectiveMapResult. (It 
 should be obvious that SelectiveMapResult is just Optional with another 
 name here.)
>>> 
>>> "selectiveMap" feels better in part due to grammar. "map" is obviously the 
>>> verb and "selective" is obviously a modification of "map". "selectiveMap" 
>>> is therefore performing some sort of special map operation. 
>>> 
>>> "filterMap" feels bad for the same reason that "selectMap" would feel worse 
>>> than "selectiveMap". "filter" and "map" are both verbs in this context. 
>>> Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
>>> "filteringMap". 
>>> 
>>> But even then "filteredMap" or "filteringMap" is insufficient to describe 
>>> the operation. You additionally need to know that the "filter" here is not 
>>> ordinary "filter", but instead the special case "filter { $0 != nil }".
>>> 
>>> 
 The name filterMap focuses on removing the ignored values, as does 
 compactMap. The name selectiveMap focuses on retaining the non-ignored 
 values. I’m not sure whether focusing on the positive or negative aspects 
 is clearer here. I don’t particularly like the name compactMap, simply 
 because I don’t have a lot of experience with languages that use “compact” 
 to mean “drop the nil values”, and without that experience it doesn’t seem 
 intuitive. I think filterMap is better. But if we introduced 
 Sequence.compact() alongside .compactMap(), I’d probably get used to it.
>>> 
>>> Swift doesn't use "filter" to mean "drop the nil values" either. 
>>> 
>>> 
>>> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
>>> operation in practice to pull its own weight?
>>> 
>>> "mapSome" is great if you know about Optional.Some but terrible if you 
>>> don't. ("Okay, it maps some elements, but which ones?") 
>>> 
>>> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a 
>>> winner.
>> 
>> mapSome and especially mapNonNil both sound to me like they only map the 
>> non-nil values in the source sequence.
> 
> I thought it did map the non-nil values in the source sequence. Did I 
> misunderstand what the proposed filterMap does? It occurs to me that the 
> proposal does not have a standalone description of the filterMap operation.

func filterMap(_ f: (Element) -> T?) -> [T] {
  return self.map(f).filter { $0 != nil }.map( $0! } // not an efficient 
implementation
}

A mapping function is applied to all elements of the source sequence.  Unlike 
map, however, the mapping function can return nil, causing that value to be 
dropped from the result sequence.  Since the result sequence can therefore not 
contain any (directly) nil values, a level of optionality is removed from the 
result element type.  A common use 

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Nevin Brackett-Rozinsky via swift-evolution]

On Wed, Nov 15, 2017 at 8:05 PM, Wallacy via swift-evolution <
swift-evolution@swift.org> wrote:

> “unwrappingMap”(or some variations using unwrap).
>

 I’d like to propose “mapAndUnwrap”.

It does what it says on the tin: map a sequence (into an optional type),
then unwrap the values which exist.

Nevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Greg Parker via swift-evolution]

> On Nov 15, 2017, at 5:53 PM, John McCall  wrote:
> 
>> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution 
>> > wrote:
>> 
>>> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
>>> > wrote:
>>> 
 On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
 > wrote:
 
 Odd… exactly that is the reason why I think filterMap is the worst choice:
 
 Both are established terms of art, but one has a meaning that doesn’t fit 
 to the operation.
 Applying filter can remove elements, but it can never change types (I feel 
 kind of silly to repeat this over and over, but so far, nobody took the 
 time to falsify this).
>>> 
>>> The concern about filter changing types is only relevant if you think of 
>>> the filter applying to the result of the map, instead of being a part of 
>>> the filterMap operation itself (an operation that is distinct from map).
>>> 
>>> Let’s imagine that we had this instead:
>>> 
>>> enum SelectiveMapResult {
>>> case use(T)
>>> case ignore
>>> }
>>> 
>>> extension Sequence {
>>> func selectiveMap(_ selectiveTransform: 
>>> (Element)->SelectiveMapResult) -> [T]
>>> }
>>> 
>>> let actualNumbers =
>>> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
>>> (x)->SelectiveMapResult in
>>> if let value = Int(x) { return .use(value) }
>>> else { return .ignore }
>>> })
>>> 
>>> actualNumbers == [1, 2, 5]
>>> 
>>> The “selective” part of this operation doesn’t feel like it’s changing the 
>>> type of the result, because SelectiveMapResult is easily understood to not 
>>> be part of the mapping transformation; it just exists to tell us whether we 
>>> should use the result of that particular transformation. Likewise, I don’t 
>>> feel like the optional in filterMap is part of the mapping operation; it’s 
>>> just serving the same role as SelectiveMapResult. (It should be obvious 
>>> that SelectiveMapResult is just Optional with another name here.)
>> 
>> "selectiveMap" feels better in part due to grammar. "map" is obviously the 
>> verb and "selective" is obviously a modification of "map". "selectiveMap" is 
>> therefore performing some sort of special map operation. 
>> 
>> "filterMap" feels bad for the same reason that "selectMap" would feel worse 
>> than "selectiveMap". "filter" and "map" are both verbs in this context. 
>> Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
>> "filteringMap". 
>> 
>> But even then "filteredMap" or "filteringMap" is insufficient to describe 
>> the operation. You additionally need to know that the "filter" here is not 
>> ordinary "filter", but instead the special case "filter { $0 != nil }".
>> 
>> 
>>> The name filterMap focuses on removing the ignored values, as does 
>>> compactMap. The name selectiveMap focuses on retaining the non-ignored 
>>> values. I’m not sure whether focusing on the positive or negative aspects 
>>> is clearer here. I don’t particularly like the name compactMap, simply 
>>> because I don’t have a lot of experience with languages that use “compact” 
>>> to mean “drop the nil values”, and without that experience it doesn’t seem 
>>> intuitive. I think filterMap is better. But if we introduced 
>>> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
>> 
>> Swift doesn't use "filter" to mean "drop the nil values" either. 
>> 
>> 
>> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
>> operation in practice to pull its own weight?
>> 
>> "mapSome" is great if you know about Optional.Some but terrible if you 
>> don't. ("Okay, it maps some elements, but which ones?") 
>> 
>> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a 
>> winner.
> 
> mapSome and especially mapNonNil both sound to me like they only map the 
> non-nil values in the source sequence.

I thought it did map the non-nil values in the source sequence. Did I 
misunderstand what the proposed filterMap does? It occurs to me that the 
proposal does not have a standalone description of the filterMap operation.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[John McCall via swift-evolution]

> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution 
>  wrote:
> 
>> 
>> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
>> > wrote:
>> 
>>> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
>>> > wrote:
>>> 
>>> Odd… exactly that is the reason why I think filterMap is the worst choice:
>>> 
>>> Both are established terms of art, but one has a meaning that doesn’t fit 
>>> to the operation.
>>> Applying filter can remove elements, but it can never change types (I feel 
>>> kind of silly to repeat this over and over, but so far, nobody took the 
>>> time to falsify this).
>> 
>> The concern about filter changing types is only relevant if you think of the 
>> filter applying to the result of the map, instead of being a part of the 
>> filterMap operation itself (an operation that is distinct from map).
>> 
>> Let’s imagine that we had this instead:
>> 
>> enum SelectiveMapResult {
>> case use(T)
>> case ignore
>> }
>> 
>> extension Sequence {
>> func selectiveMap(_ selectiveTransform: 
>> (Element)->SelectiveMapResult) -> [T]
>> }
>> 
>> let actualNumbers =
>> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
>> (x)->SelectiveMapResult in
>> if let value = Int(x) { return .use(value) }
>> else { return .ignore }
>> })
>> 
>> actualNumbers == [1, 2, 5]
>> 
>> The “selective” part of this operation doesn’t feel like it’s changing the 
>> type of the result, because SelectiveMapResult is easily understood to not 
>> be part of the mapping transformation; it just exists to tell us whether we 
>> should use the result of that particular transformation. Likewise, I don’t 
>> feel like the optional in filterMap is part of the mapping operation; it’s 
>> just serving the same role as SelectiveMapResult. (It should be obvious that 
>> SelectiveMapResult is just Optional with another name here.)
> 
> "selectiveMap" feels better in part due to grammar. "map" is obviously the 
> verb and "selective" is obviously a modification of "map". "selectiveMap" is 
> therefore performing some sort of special map operation. 
> 
> "filterMap" feels bad for the same reason that "selectMap" would feel worse 
> than "selectiveMap". "filter" and "map" are both verbs in this context. 
> Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
> "filteringMap". 
> 
> But even then "filteredMap" or "filteringMap" is insufficient to describe the 
> operation. You additionally need to know that the "filter" here is not 
> ordinary "filter", but instead the special case "filter { $0 != nil }".
> 
> 
>> The name filterMap focuses on removing the ignored values, as does 
>> compactMap. The name selectiveMap focuses on retaining the non-ignored 
>> values. I’m not sure whether focusing on the positive or negative aspects is 
>> clearer here. I don’t particularly like the name compactMap, simply because 
>> I don’t have a lot of experience with languages that use “compact” to mean 
>> “drop the nil values”, and without that experience it doesn’t seem 
>> intuitive. I think filterMap is better. But if we introduced 
>> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
> 
> Swift doesn't use "filter" to mean "drop the nil values" either. 
> 
> 
> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
> operation in practice to pull its own weight?
> 
> "mapSome" is great if you know about Optional.Some but terrible if you don't. 
> ("Okay, it maps some elements, but which ones?") 
> 
> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a winner.

mapSome and especially mapNonNil both sound to me like they only map the 
non-nil values in the source sequence.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Wallacy via swift-evolution]

I vote for “mapNonNil”, “mapDroppingNil” or “unwrappingMap”(or some
variations using unwrap).

It’s not pretty, but does the job!



Em qua, 15 de nov de 2017 às 22:36, Greg Parker via swift-evolution <
swift-evolution@swift.org> escreveu:

> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Odd… exactly that is the reason why I think filterMap is the worst choice:
>
>
> Both are established terms of art, but one has a meaning that doesn’t fit
> to the operation.
> Applying filter can remove elements, but it can never change types (I feel
> kind of silly to repeat this over and over, but so far, nobody took the
> time to falsify this).
>
>
> The concern about filter changing types is only relevant if you think of
> the filter applying to the *result* of the map, instead of being a part
> of the filterMap operation itself (an operation that is distinct from map
> ).
>
> Let’s imagine that we had this instead:
>
> enum SelectiveMapResult {
> case use(T)
> case ignore
> }
>
> extension Sequence {
> func selectiveMap(_ selectiveTransform: (Element)->
> SelectiveMapResult) -> [T]
> }
>
> let actualNumbers =
> ["1", "2", "apple", "banana", "5"].selectiveMap({ (x)->
> SelectiveMapResult in
> if let value = Int(x) { return .use(value) }
> else { return .ignore }
> })
>
> actualNumbers == [1, 2, 5]
>
>
> The “selective” part of this operation doesn’t feel like it’s changing the
> type of the result, because SelectiveMapResult is easily understood to
> not be part of the mapping transformation; it just exists to tell us
> whether we should *use the result* of that particular transformation.
> Likewise, I don’t feel like the optional in filterMap is part of the
> mapping operation; it’s just serving the same role as SelectiveMapResult.
> (It should be obvious that SelectiveMapResult is just Optional with
> another name here.)
>
>
> "selectiveMap" feels better in part due to grammar. "map" is obviously the
> verb and "selective" is obviously a modification of "map". "selectiveMap"
> is therefore performing some sort of special map operation.
>
> "filterMap" feels bad for the same reason that "selectMap" would feel
> worse than "selectiveMap". "filter" and "map" are both verbs in this
> context. Grammatically the analogue to "selectiveMap" would be
> "filteredMap" or "filteringMap".
>
> But even then "filteredMap" or "filteringMap" is insufficient to describe
> the operation. You additionally need to know that the "filter" here is not
> ordinary "filter", but instead the special case "filter { $0 != nil }".
>
>
> The name filterMap focuses on removing the ignored values, as does
> compactMap. The name selectiveMap focuses on retaining the non-ignored
> values. I’m not sure whether focusing on the positive or negative aspects
> is clearer here. I don’t particularly like the name compactMap, simply
> because I don’t have a lot of experience with languages that use “compact”
> to mean “drop the nil values”, and without that experience it doesn’t seem
> intuitive. I think filterMap is better. But if we introduced
> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
>
>
> Swift doesn't use "filter" to mean "drop the nil values" either.
>
>
> "compactMap" is okay if "compact" is added. Is "compact" a common enough
> operation in practice to pull its own weight?
>
> "mapSome" is great if you know about Optional.Some but terrible if you
> don't. ("Okay, it maps some elements, but which ones?")
>
> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a
> winner.
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
> ___
> 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

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Jon Shier via swift-evolution]

Having watched this discussion without much opinion before, I’ve found 
the argument about the meaning of map in a functional context to be somewhat 
convincing. While Swift isn’t a pure functional language, I think having the 
concept of a `map` generally mean a 1:1 mapping between input and output to be 
a good bit of consistency when thinking about it abstractly. Therefore I think 
a new verb is necessary, so compact is my choice, similar to flatten. While it 
could be considered a very specific version of filter, I think that it can 
stand on its own, as it also unwraps. So compact() would compact any array of 
optionals and compactMap() would map and then compact. While that sort of map 
isn’t 1:1, it’s in the line of normal flatMap, where the transform may change 
the number of elements in the result beyond a simple flattening of the array.
As for popularity, personally I compact arrays of optionals far more 
than I flatten arrays of arrays. It’s especially useful in dealing with 
Objective-C types. 
Additionally, I think the logic I’ve just described justifies a 
flatten/flattened function to parallel flatMap. I know it would simplify my 
code, as I’m usually only flattening a single level of array without a 
transform.


Jon Shier

> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution 
>  wrote:
> 
>> 
>> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
>> > wrote:
>> 
>>> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
>>> > wrote:
>>> 
>>> Odd… exactly that is the reason why I think filterMap is the worst choice:
>>> 
>>> Both are established terms of art, but one has a meaning that doesn’t fit 
>>> to the operation.
>>> Applying filter can remove elements, but it can never change types (I feel 
>>> kind of silly to repeat this over and over, but so far, nobody took the 
>>> time to falsify this).
>> 
>> The concern about filter changing types is only relevant if you think of the 
>> filter applying to the result of the map, instead of being a part of the 
>> filterMap operation itself (an operation that is distinct from map).
>> 
>> Let’s imagine that we had this instead:
>> 
>> enum SelectiveMapResult {
>> case use(T)
>> case ignore
>> }
>> 
>> extension Sequence {
>> func selectiveMap(_ selectiveTransform: 
>> (Element)->SelectiveMapResult) -> [T]
>> }
>> 
>> let actualNumbers =
>> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
>> (x)->SelectiveMapResult in
>> if let value = Int(x) { return .use(value) }
>> else { return .ignore }
>> })
>> 
>> actualNumbers == [1, 2, 5]
>> 
>> The “selective” part of this operation doesn’t feel like it’s changing the 
>> type of the result, because SelectiveMapResult is easily understood to not 
>> be part of the mapping transformation; it just exists to tell us whether we 
>> should use the result of that particular transformation. Likewise, I don’t 
>> feel like the optional in filterMap is part of the mapping operation; it’s 
>> just serving the same role as SelectiveMapResult. (It should be obvious that 
>> SelectiveMapResult is just Optional with another name here.)
> 
> "selectiveMap" feels better in part due to grammar. "map" is obviously the 
> verb and "selective" is obviously a modification of "map". "selectiveMap" is 
> therefore performing some sort of special map operation. 
> 
> "filterMap" feels bad for the same reason that "selectMap" would feel worse 
> than "selectiveMap". "filter" and "map" are both verbs in this context. 
> Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
> "filteringMap". 
> 
> But even then "filteredMap" or "filteringMap" is insufficient to describe the 
> operation. You additionally need to know that the "filter" here is not 
> ordinary "filter", but instead the special case "filter { $0 != nil }".
> 
> 
>> The name filterMap focuses on removing the ignored values, as does 
>> compactMap. The name selectiveMap focuses on retaining the non-ignored 
>> values. I’m not sure whether focusing on the positive or negative aspects is 
>> clearer here. I don’t particularly like the name compactMap, simply because 
>> I don’t have a lot of experience with languages that use “compact” to mean 
>> “drop the nil values”, and without that experience it doesn’t seem 
>> intuitive. I think filterMap is better. But if we introduced 
>> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
> 
> Swift doesn't use "filter" to mean "drop the nil values" either. 
> 
> 
> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
> operation in practice to pull its own weight?
> 
> "mapSome" is great if you know about Optional.Some but terrible if you don't. 
> ("Okay, it maps some elements, but which ones?") 
> 
> "mapNonNil" is obvious and ugly 

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Greg Parker via swift-evolution]

> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
>  wrote:
> 
>> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
>> > wrote:
>> 
>> Odd… exactly that is the reason why I think filterMap is the worst choice:
>> 
>> Both are established terms of art, but one has a meaning that doesn’t fit to 
>> the operation.
>> Applying filter can remove elements, but it can never change types (I feel 
>> kind of silly to repeat this over and over, but so far, nobody took the time 
>> to falsify this).
> 
> The concern about filter changing types is only relevant if you think of the 
> filter applying to the result of the map, instead of being a part of the 
> filterMap operation itself (an operation that is distinct from map).
> 
> Let’s imagine that we had this instead:
> 
> enum SelectiveMapResult {
> case use(T)
> case ignore
> }
> 
> extension Sequence {
> func selectiveMap(_ selectiveTransform: 
> (Element)->SelectiveMapResult) -> [T]
> }
> 
> let actualNumbers =
> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
> (x)->SelectiveMapResult in
> if let value = Int(x) { return .use(value) }
> else { return .ignore }
> })
> 
> actualNumbers == [1, 2, 5]
> 
> The “selective” part of this operation doesn’t feel like it’s changing the 
> type of the result, because SelectiveMapResult is easily understood to not be 
> part of the mapping transformation; it just exists to tell us whether we 
> should use the result of that particular transformation. Likewise, I don’t 
> feel like the optional in filterMap is part of the mapping operation; it’s 
> just serving the same role as SelectiveMapResult. (It should be obvious that 
> SelectiveMapResult is just Optional with another name here.)

"selectiveMap" feels better in part due to grammar. "map" is obviously the verb 
and "selective" is obviously a modification of "map". "selectiveMap" is 
therefore performing some sort of special map operation. 

"filterMap" feels bad for the same reason that "selectMap" would feel worse 
than "selectiveMap". "filter" and "map" are both verbs in this context. 
Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
"filteringMap". 

But even then "filteredMap" or "filteringMap" is insufficient to describe the 
operation. You additionally need to know that the "filter" here is not ordinary 
"filter", but instead the special case "filter { $0 != nil }".


> The name filterMap focuses on removing the ignored values, as does 
> compactMap. The name selectiveMap focuses on retaining the non-ignored 
> values. I’m not sure whether focusing on the positive or negative aspects is 
> clearer here. I don’t particularly like the name compactMap, simply because I 
> don’t have a lot of experience with languages that use “compact” to mean 
> “drop the nil values”, and without that experience it doesn’t seem intuitive. 
> I think filterMap is better. But if we introduced Sequence.compact() 
> alongside .compactMap(), I’d probably get used to it.

Swift doesn't use "filter" to mean "drop the nil values" either. 


"compactMap" is okay if "compact" is added. Is "compact" a common enough 
operation in practice to pull its own weight?

"mapSome" is great if you know about Optional.Some but terrible if you don't. 
("Okay, it maps some elements, but which ones?") 

"mapNonNil" is obvious and ugly and perhaps its obviousness makes it a winner.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Hugo Hennies via swift-evolution]

I'd like to show my support for mapSome. It's clear, concise and to the point. 
It's the best name from all the alternatives IMHO

> On Nov 15, 2017, at 7:15 PM, Ben Cohen via swift-evolution 
>  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 
>>  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
>> 
>> 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
>> 
>> 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
>> 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
>> 
>> As always, thank you for contributing to the evolution of Swift.
>> 
>> John McCall
>> Review Manager
>> ___
>> 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
___
swift-evolution mailing list

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[BJ Homer via swift-evolution]

> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> Odd… exactly that is the reason why I think filterMap is the worst choice:
> 
> Both are established terms of art, but one has a meaning that doesn’t fit to 
> the operation.
> Applying filter can remove elements, but it can never change types (I feel 
> kind of silly to repeat this over and over, but so far, nobody took the time 
> to falsify this).

The concern about filter changing types is only relevant if you think of the 
filter applying to the result of the map, instead of being a part of the 
filterMap operation itself (an operation that is distinct from map).

Let’s imagine that we had this instead:

enum SelectiveMapResult {
case use(T)
case ignore
}

extension Sequence {
func selectiveMap(_ selectiveTransform: 
(Element)->SelectiveMapResult) -> [T]
}

let actualNumbers =
["1", "2", "apple", "banana", "5"].selectiveMap({ 
(x)->SelectiveMapResult in
if let value = Int(x) { return .use(value) }
else { return .ignore }
})

actualNumbers == [1, 2, 5]

The “selective” part of this operation doesn’t feel like it’s changing the type 
of the result, because SelectiveMapResult is easily understood to not be part 
of the mapping transformation; it just exists to tell us whether we should use 
the result of that particular transformation. Likewise, I don’t feel like the 
optional in filterMap is part of the mapping operation; it’s just serving the 
same role as SelectiveMapResult. (It should be obvious that SelectiveMapResult 
is just Optional with another name here.)

The name filterMap focuses on removing the ignored values, as does compactMap. 
The name selectiveMap focuses on retaining the non-ignored values. I’m not sure 
whether focusing on the positive or negative aspects is clearer here. I don’t 
particularly like the name compactMap, simply because I don’t have a lot of 
experience with languages that use “compact” to mean “drop the nil values”, and 
without that experience it doesn’t seem intuitive. I think filterMap is better. 
But if we introduced Sequence.compact() alongside .compactMap(), I’d probably 
get used to it.

-BJ


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Tino Heth via swift-evolution]

> I’m happy that the rename was accepted. I’d like to support renaming it to 
> filterMap because it uses two terms of art already pre-existing and 
> understood by the Swift community
Odd… exactly that is the reason why I think filterMap is the worst choice:
Both are established terms of art, but one has a meaning that doesn’t fit to 
the operation.
Applying filter can remove elements, but it can never change types (I feel kind 
of silly to repeat this over and over, but so far, nobody took the time to 
falsify this).

So, I’d rather introduce a unburnt word than reuse an existing term that 
conveys a wrong message. Honestly, I’d consider „reduceMap“ less bad… but I 
can’t see any good reason to limit the choice to something that is already used 
in Swift — after all, we don’t have to pay for new names.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Stephen Celis via swift-evolution]

> On Nov 15, 2017, at 4:15 PM, David Hart via swift-evolution 
>  wrote:
> 
> I’m very much against a term like compactMap because it uses the term compact 
> which has no precedence in Swift’s Standard Library.

I don’t really care what the name ends up being (as long as it’s not 
“flatMap”), but you do bring up something worth addressing.

I imagine a majority of calls to this function are of the lines of “compactMap 
{ $0 }”, so maybe it’s worth adding a helper/alias like “compact()”?

Stephen
https://www.pointfree.co___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[David Hart via swift-evolution]

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 
>  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 
>> > 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
>>  
>> 
>> 
>> 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 
>> 
>> 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
>>  
>> 
>> 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 
>> 
>> 
>> As always, thank you for contributing to the evolution of Swift.
>> 
>> John McCall
>> Review Manager
>> 

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[David Hart via swift-evolution]

> On 15 Nov 2017, at 21:55, John McCall via swift-evolution 
>  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
>  
> 
> 
> 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 
> 
> 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
>  
> 
> 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?

I’m happy that the rename was accepted. I’d like to support renaming it to 
filterMap because it uses two terms of art already pre-existing and understood 
by the Swift community: map makes it clear it is an operation on a Sequence, 
while filter makes it clear that the resulting array may be smaller than 
original array.

I’m very much against a term like compactMap because it uses the term compact 
which has no precedence in Swift’s Standard Library.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Yes, but I think that comparing with other languages (like Ruby for compactMap) 
is not the right approach. We need to choose a name which feels at home in the 
Standard Library.

>   • 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 
> 
> 
> As always, thank you for contributing to the evolution of 

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Ben Cohen via swift-evolution]

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 
>  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
>  
> 
> 
> 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 
> 
> 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
>  
> 
> 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 
> 
> 
> As always, thank you for contributing to the evolution of Swift.
> 
> John McCall
> Review Manager
> ___
> 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