[SHORT Review] SE-0133: Rename `flatten()` to `joined()`

Evolution Announcements
1

Hello Swift community,

The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

  swift-evolution/0133-rename-flatten-to-joined.md at master · apple/swift-evolution · GitHub

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 the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

2

Hello Swift community,

The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and
runs through July 26. Apologies for the short review cycle, but we’re
right up against the end of source breaking changes for Swift 3. The
proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md

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 the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to 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?

+1. A sensible simplification of the public API. Moreover, `flatten()` was
apparently treated as a term-of-art and doesn't observe the noun/verb
guidelines for non-mutating vs. mutating methods. So `joined()` is the
superior choice.

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

Sure; unnecessary inconsistency in the stdlib APIs are best reduced or
eliminated where possible.

        * 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?

It reminds me of Python `join`, although in that language the default
separator for joining strings is " ". Arguably, a more convenient default
for Western languages, but a more universally appropriate default would
indeed be "" as proposed.

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

A quick reading, but followed the original discussion.

···

On Mon, Jul 25, 2016 at 1:10 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Hello Swift community,

The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md

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 the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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?

-1

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

I don't thinks so.

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

I think we would loose readability. I appreciate having flatten() specially when I have to combine it with joined().

This to me would be unfortunate when reading:
[["hey"], ["what"]].joined().joined()

   * 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?

Participated in thread.

···

On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

Shouldn't the proposal also mention renaming FlattenCollection, FlattenBidirectionalCollection and FlattenSequence to Joined*(Collection|Sequence)? Or are these going to keep their name?

···

On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md

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 the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

+1

Simple obvious improvement.

Scott

6

  * What is your evaluation of the proposal?

-1. I find the motivation section troubling. It’s simply an assertion that this “should” happen. From reading the rest of the proposed text as well as others reviews in support, I get the impression that combining flatten and joined results in an API that’s more “pleasing” to some because they do similar things.

IMO, the fact that they are similar is why we should *not* give them the same name. In summary, we would be trading 2 simpler APIs to a complex one. I don’t believe that’s a goal for Swift.

Both methods returns a corresponding Sequence, FlattenSequence and JoinedSequence. Creating a FlattenSequence is always lazy and has O(1) complexity, iterating over it is also a simple and efficient process. JoinedSequence on the other hand, has O(length_of_separator) complexity at init, and involves additional state juggling at iteration. Yes, if the separator is skipped, we could make the new `joined` behave exactly like `flatten`, and put its merits in the documentation, and warn them about the complexity difference, and explain whether/how it’s different to provide “” and nil when calling this on a string…

Hopefully, you can see why I’d rather give user `flatten` when that’s all they are looking for.

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

No.

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

Maybe. Less sometimes is good. But in this case it incurs a cost.

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

flatten is a well understood and commonly used operation in many PLs.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

read the proposal and posts on this list.

···

On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

7

I'm giving the overall idea a +0 and the specific proposal as currently
written a -1, because I think this is a much more complicated bikeshed
than it appears to be on the surface and the proposal doesn't begin to
address the issues. Specifically, I'm concerned about these points:

* `flatten` works on Optional<Optional<T>> and sequences of Optional<T>.
  How does it make sense to rename these operations “join?”

* The name and semantics of `flatten` is linked to that of `flatMap`.
  It's almost impossible to explain what `flatMap` does without
  reference to `flatten`. Will it make sense to explain `flatMap` in
  terms of `joined`?

* `flatten` is a functional term of art in the same family as `flatMap`.
  We have good reasons to consider changing some of the other names in
  this family, such as `filter` and `reduce`, but that idea has met with
  significant resistance on the list. How far should we go? Does it
  make sense to make this one change alone?

I could be convinced to change my evaluation of the proposal if there
are good answers to these questions, but until then, I'm not won over.

···

on Sun Jul 24 2016, Chris Lattner <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0133: Rename `flatten()` to `joined()`" begins now
and runs through July 26. Apologies for the short review cycle, but
we’re right up against the end of source breaking changes for Swift 3.
The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md

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 the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to 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

--
Dave

8

The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md

  * What is your evaluation of the proposal?

+1, this makes sense. The functions are very closely related, and while we have "flatten" in `flatMap`, is isn't unprecedented to call the joining operation `join` instead of `flatten`.

Flatten also somewhat suffers from the expectation that it would flatten arbitrary depths of nestings down to just one. (That would be absurd in Swift's type system, but is precedented in e.g. Clojure <clojure.core - Clojure v1.11 API documentation) The word "join" instead sounds like a more 1-dimensional operation, and thus decreases the minor surprise factor.

It's also nice that `.joined(separator:)` can be simplified down to `.joined()` when the default separator is wanted. And I'd say the empty collection is an obvious choice for default in here.

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

Yes, it makes the function easier to find.

  * 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. E.g. Haskell calls it `join` <Control.Monad.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

— Pyry

···

On 25 Jul 2016, at 09:10, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

9

  * What is your evaluation of the proposal?

+1 This makes total sense. I was going to voice my disagreement until I saw that I did not understand what the APIs did because of their names :D The renaming makes things much clearer.

  * 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?

Even if some languages have flatten, it does seem like a special case of joined.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read.

10

* What is your evaluation of the proposal?
+1. It's consistent with the new language guidelines, and though 'flatten' seemed a term-of-art there are multiple arguments here that would clear up things, like the string combination.

   * 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. It is consistent with the direction of things, and streamlines APIs.

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick reading.

···

On 25 Jul. 2016, at 4:10 pm, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

   * 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?

11

   * What is your evaluation of the proposal?

-1. I think that there might be something to this idea, but am against the proposal in its current form for the same reasons that have already been stated: flatten has a broader use than just joining sequences/collections, and flatten as a name is strongly related to flatMap.

Not merging "flatten" and "joined" but still adding the default arguments would make the similarities between the two even more confusing.

The name of the merged function (if any) needs more consideration, taking into account it's broader context and future use.

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

Not sure.

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

No. In its current form it's almost an oversimplification.

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

Haskell calls the general m (m a) -> m a function for "join", but also has a specialized [[a]] -> [a] function called "concat". (The function corresponding to "flatMap" is called "bind" in Haskell (although used as an operator), so since neither is called flatten or flatMap it doesn't have the confusion where one of them would be named so).

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal.

- David

12

What is your evaluation of the proposal?

-1

- Certainly `flatten` and `joined` work similarly. I think, however,
the concepts behind them are different. When I use `flatten`, I want
to make nested monads flat. When I use `joined`, I want to concatenate
sequences, mainly `String`s, with a separator. So it is clearer for me
that `flatten` is separated from `joined`.
- `flatMap` means `map` + `flatten`. I feel `flatMap` with `joined`
does not make sense.

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

No. It is not a problem for me as described above.

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

I think proposed `joined` itself fits with the feel of Swift but it is
not the direction of Swift. It can cause problems to unite things
which just look similar ignoring the concepts behind them.

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

Kotlin has `flatten` and `flatMap`. Although Haskell has `join` as
`flatten`, it's `flatMap` is named `>>=` (bind).

I don't know any languages which have a combination of `joined` and
`flatMap`. I feel it is strange.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading the thread.

-- Yuta Koshizawa

···

2016-07-25 15:10 GMT+09:00 Chris Lattner via swift-evolution <swift-evolution@swift.org>:

Hello Swift community,

The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

        https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md

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 the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

13

I wasn't explicit about that in the proposal, but I was intending that
these should be renamed too. There's a minor snag: JoinedSequence already
exists. I haven't taken a close look at both implementations yet, but it's
possible we could just combine them.

···

On Mon, Jul 25, 2016 at 12:46 AM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote:

Shouldn't the proposal also mention renaming FlattenCollection,
FlattenBidirectionalCollection and FlattenSequence to
Joined*(Collection|Sequence)? Or are these going to keep their name?

> On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and
runs through July 26. Apologies for the short review cycle, but we’re
right up against the end of source breaking changes for Swift 3. The
proposal is available here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
>
> 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 the
review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to 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
>
> Thank you,
>
> -Chris Lattner
> 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

14

I'm giving the overall idea a +0 and the specific proposal as currently
written a -1, because I think this is a much more complicated bikeshed
than it appears to be on the surface and the proposal doesn't begin to
address the issues. Specifically, I'm concerned about these points:

* `flatten` works on Optional<Optional<T>> and sequences of Optional<T>.
  How does it make sense to rename these operations “join?”

Does it really? These don't work for me:

let x = [1,2,nil,4]
x.flatten()

let y = Optional(Optional(42))
y.flatten()

* The name and semantics of `flatten` is linked to that of `flatMap`.
  It's almost impossible to explain what `flatMap` does without
  reference to `flatten`. Will it make sense to explain `flatMap` in
  terms of `joined`?

I think the current documentation comments do a pretty good job:

On the [T].flatMap(T -> U?) -> [U] version:
  /// Returns an array containing the non-`nil` results of calling the given
  /// transformation with each element of this sequence.

On the [T].flatMap(T -> [U]) -> [U] version:
  /// Returns an array containing the concatenated results of calling the
  /// given transformation with each element of this sequence.

(This one also mentions array.map(transform).flatten(), which would become
array.map(transform).joined().)

* `flatten` is a functional term of art in the same family as `flatMap`.
  We have good reasons to consider changing some of the other names in
  this family, such as `filter` and `reduce`, but that idea has met with
  significant resistance on the list. How far should we go? Does it
  make sense to make this one change alone?

I wouldn't argue for renaming flatMap. I'm not suggesting to change the
name of flatten() because I don't like it (I do); I'm suggesting to change
it because — unlike Ruby, whose Array has #flatten and #join, but the
latter is *only* for producing strings — we seem to have the *same*
functionality behind 2 differently-named APIs.

(Actually I feel like flatMap is a more fundamental functional method in
the family of filter and reduce than flatten/joined is. flatten is just
flatMap({$0}), although as pointed out above, flatten isn't actually
available in all the places that flatMap({$0}) would work.)

Jacob

···

On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

15

There's also mapMaybe
<Data.Maybe;
and concatMap
<Prelude;
and
mapM
<Prelude; and
probably others. "concat" is just "concatMap id". Similarly, concatMap can
be seen as equivalent to bind with its arguments reversed, "flip (>>=)". I
personally find the plethora of similar functions confusing, but I'm not
totally fluent in Haskell's standard libraries.

···

On Mon, Jul 25, 2016 at 2:09 PM, David Rönnqvist <swift-evolution@swift.org> wrote:

Haskell calls the general *m (m a) -> m a* function for "join", but also
has a specialized *[[a]] -> [a]* function called "concat". (The function
corresponding to "flatMap" is called "bind" in Haskell (although used as an
operator), so since neither is called flatten or flatMap it doesn't have
the confusion where one of them would be named so).

16

I'm basically in agreement with Dave here. This is worth a lot more thought than we have time to put in right now, and the cost of waiting is a deprecation cycle on n+1 methods instead of n methods. Let's defer until 3.1 and have a proper think about it with a wider scope than just `flatten()`.

···

On Jul 25, 2016, at 1:11 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

I'm giving the overall idea a +0 and the specific proposal as currently
written a -1, because I think this is a much more complicated bikeshed
than it appears to be on the surface and the proposal doesn't begin to
address the issues. Specifically, I'm concerned about these points:

* `flatten` works on Optional<Optional<T>> and sequences of Optional<T>.
How does it make sense to rename these operations “join?”

* The name and semantics of `flatten` is linked to that of `flatMap`.
It's almost impossible to explain what `flatMap` does without
reference to `flatten`. Will it make sense to explain `flatMap` in
terms of `joined`?

* `flatten` is a functional term of art in the same family as `flatMap`.
We have good reasons to consider changing some of the other names in
this family, such as `filter` and `reduce`, but that idea has met with
significant resistance on the list. How far should we go? Does it
make sense to make this one change alone?

I could be convinced to change my evaluation of the proposal if there
are good answers to these questions, but until then, I'm not won over.

--
Brent Royal-Gordon
Architechies

17

I'm giving the overall idea a +0 and the specific proposal as currently
written a -1, because I think this is a much more complicated bikeshed
than it appears to be on the surface and the proposal doesn't begin to
address the issues. Specifically, I'm concerned about these points:

* `flatten` works on Optional<Optional<T>> and sequences of Optional<T>.
  How does it make sense to rename these operations “join?”

Does it really? These don't work for me:

let x = [1,2,nil,4]
x.flatten()

let y = Optional(Optional(42))
y.flatten()

Agh. Well, hello, bug! It's supposed to, IMO, for the same reason that
flatMap does. The relationship is that

  x.flatten() === x.flatMap {$0}

So how would you document the semantics of

   Optional(Optional(42)).joined()

* The name and semantics of `flatten` is linked to that of `flatMap`.
  It's almost impossible to explain what `flatMap` does without
  reference to `flatten`. Will it make sense to explain `flatMap` in
  terms of `joined`?

I think the current documentation comments do a pretty good job:

On the [T].flatMap(T -> U?) -> [U] version:
  /// Returns an array containing the non-`nil` results of calling the given
  /// transformation with each element of this sequence.

On the [T].flatMap(T -> [U]) -> [U] version:
  /// Returns an array containing the concatenated results of calling the
  /// given transformation with each element of this sequence.

(This one also mentions array.map(transform).flatten(), which would become
array.map(transform).joined().)

Okay.

* `flatten` is a functional term of art in the same family as `flatMap`.
  We have good reasons to consider changing some of the other names in
  this family, such as `filter` and `reduce`, but that idea has met with
  significant resistance on the list. How far should we go? Does it
  make sense to make this one change alone?

I wouldn't argue for renaming flatMap. I'm not suggesting to change the
name of flatten() because I don't like it (I do); I'm suggesting to change
it because — unlike Ruby, whose Array has #flatten and #join, but the
latter is *only* for producing strings — we seem to have the *same*
functionality behind 2 differently-named APIs.

(Actually I feel like flatMap is a more fundamental functional method in
the family of filter and reduce than flatten/joined is. flatten is just
flatMap({$0}),

x.map(f) can be written as x.flatMap(Optional(f)) or even x.flatMap(f)
for that matter. Does that make flatMap more fundamental than map? ;-)

Something roughly like this holds:

  flatMap = map • flatten
  map = flatMap • Optional
  flatten = flatMap • identity

···

on Mon Jul 25 2016, Jacob Bandes-Storch <jtbandes-AT-gmail.com> wrote:

On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

--
Dave