[Pitch] Unify joined(separator:) and flatten()

Evolution Pitches
1

In the swift-lang Slack channel, a few of us were discussing
joined(separator:) and realized that flatten() does almost exactly the same
thing.

Is there interest in renaming flatten() to joined()? Since joined takes a
separator that's any Sequence, we can't have a default value for the
separator parameter, but we can have a variant of joined() with no
arguments.

Jacob

2

I'd like default separators for the joined() methods.

<Issues · apple/swift-issues · GitHub;

But renaming flatten() to joined() seems complicated.

<https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb&gt;
<https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift&gt;

And what would happen to the flatMap() methods? Is flatten() a term of art?

<https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift&gt;

-- Ben

···

On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:

In the swift-lang Slack channel, a few of us were discussing joined(separator:) and realized that flatten() does almost exactly the same thing.

Is there interest in renaming flatten() to joined()? Since joined takes a separator that's any Sequence, we can't have a default value for the separator parameter, but we can have a variant of joined() with no arguments.

3

>
> In the swift-lang Slack channel, a few of us were discussing
joined(separator:) and realized that flatten() does almost exactly the same
thing.
>
> Is there interest in renaming flatten() to joined()? Since joined takes
a separator that's any Sequence, we can't have a default value for the
separator parameter, but we can have a variant of joined() with no
arguments.

I'd like default separators for the joined() methods.

<Issues · apple/swift-issues · GitHub;

But renaming flatten() to joined() seems complicated.

<
https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
>
<https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift&gt;

What makes it seem complicated? At the very least, one could just rename
the flatten() function. There might also be an opportunity to combine the
two files and delete some code from stdlib.

And what would happen to the flatMap() methods? Is flatten() a term of art?

<
https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
>

I'd say flatMap is more a "term of art" than flatten. "flatten" just
describes literally what is being done. Frankly I'm surprised it was never
named flattened(). Anyway, flatMap should stay.

···

On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington <me@benrimmington.com> wrote:

> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:

-- Ben

4

In the swift-lang Slack channel, a few of us were discussing joined(separator:) and realized that flatten() does almost exactly the same thing.

Is there interest in renaming flatten() to joined()? Since joined takes a separator that's any Sequence, we can't have a default value for the separator parameter, but we can have a variant of joined() with no arguments.

I'd like default separators for the joined() methods.

<Issues · apple/swift-issues · GitHub;

But renaming flatten() to joined() seems complicated.

<https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb&gt;
<https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift&gt;

What makes it seem complicated? At the very least, one could just rename the flatten() function. There might also be an opportunity to combine the two files and delete some code from stdlib.

There's only one joined() method (for a sequence of sequences):

  extension Sequence {
    func joined<Separator: Sequence>(separator: Separator) -> JoinedSequence<Self>
  }

There are many flatten() methods (`where` clauses omitted for brevity):

  extension Sequence {
    func flatten() -> FlattenSequence<Self>
  }

  extension LazySequenceProtocol {
    func flatten() -> LazySequence<FlattenSequence<Self.Elements>>
  }

  extension LazyCollectionProtocol {
    func flatten() -> LazyCollection<FlattenCollection<Self.Elements>>
  }

  extension Collection {
    func flatten() -> FlattenCollection<Self>
  }

  extension BidirectionalCollection {
    func flatten() -> FlattenBidirectionalCollection<Self>
  }

So it's not a simple one-to-one rename.

When there's no `separator` argument, will FlattenIterator perform better than JoinedIterator?

And what would happen to the flatMap() methods? Is flatten() a term of art?

<https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift&gt;

I'd say flatMap is more a "term of art" than flatten. "flatten" just describes literally what is being done. Frankly I'm surprised it was never named flattened(). Anyway, flatMap should stay.

## Future directions

Will the flatMap(_:) methods also have flatMap(separator:_:) variants?

-- Ben

···

On 22 Jul 2016, at 20:43, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington <me@benrimmington.com> wrote:

On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:

5

Here's a proposal draft. Comments welcome:

https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325

>
>>
>>>
>>> In the swift-lang Slack channel, a few of us were discussing
joined(separator:) and realized that flatten() does almost exactly the same
thing.
>>>
>>> Is there interest in renaming flatten() to joined()? Since joined
takes a separator that's any Sequence, we can't have a default value for
the separator parameter, but we can have a variant of joined() with no
arguments.
>>
>> I'd like default separators for the joined() methods.
>>
>> <Issues · apple/swift-issues · GitHub;
>>
>> But renaming flatten() to joined() seems complicated.
>>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift&gt;
>
> What makes it seem complicated? At the very least, one could just rename
the flatten() function. There might also be an opportunity to combine the
two files and delete some code from stdlib.

There's only one joined() method (for a sequence of sequences):

        extension Sequence {
          func joined<Separator: Sequence>(separator: Separator) ->
JoinedSequence<Self>
        }

There are many flatten() methods (`where` clauses omitted for brevity):

        extension Sequence {
          func flatten() -> FlattenSequence<Self>
        }

        extension LazySequenceProtocol {
          func flatten() -> LazySequence<FlattenSequence<Self.Elements>>
        }

        extension LazyCollectionProtocol {
          func flatten() ->
LazyCollection<FlattenCollection<Self.Elements>>
        }

        extension Collection {
          func flatten() -> FlattenCollection<Self>
        }

        extension BidirectionalCollection {
          func flatten() -> FlattenBidirectionalCollection<Self>
        }

So it's not a simple one-to-one rename.

When there's no `separator` argument, will FlattenIterator perform better
than JoinedIterator?

>> And what would happen to the flatMap() methods? Is flatten() a term of
art?
>>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
>
>
> I'd say flatMap is more a "term of art" than flatten. "flatten" just
describes literally what is being done. Frankly I'm surprised it was never
named flattened(). Anyway, flatMap should stay.

## Future directions

Will the flatMap(_:) methods also have flatMap(separator:_:) variants?

That's an interesting idea. It seems to be purely additive, however, so I
imagine it wouldn't happen until after Swift 3.

···

On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington <me@benrimmington.com> wrote:

> On 22 Jul 2016, at 20:43, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:
>> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington <me@benrimmington.com> > wrote:
>>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:

-- Ben

6

-1 for this. To me there needs to be a difference between String (which is not a normal collection) and other regular collections.

In addition, I really don’t think this proposal has the needed strong support for the change.

···

On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

Here's a proposal draft. Comments welcome:

https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325

On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington <me@benrimmington.com <mailto:me@benrimmington.com>> wrote:

> On 22 Jul 2016, at 20:43, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
>
>> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington <me@benrimmington.com <mailto:me@benrimmington.com>> wrote:
>>
>>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>>
>>> In the swift-lang Slack channel, a few of us were discussing joined(separator:) and realized that flatten() does almost exactly the same thing.
>>>
>>> Is there interest in renaming flatten() to joined()? Since joined takes a separator that's any Sequence, we can't have a default value for the separator parameter, but we can have a variant of joined() with no arguments.
>>
>> I'd like default separators for the joined() methods.
>>
>> <Issues · apple/swift-issues · GitHub;
>>
>> But renaming flatten() to joined() seems complicated.
>>
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb&gt;
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift&gt;
>
> What makes it seem complicated? At the very least, one could just rename the flatten() function. There might also be an opportunity to combine the two files and delete some code from stdlib.

There's only one joined() method (for a sequence of sequences):

        extension Sequence {
          func joined<Separator: Sequence>(separator: Separator) -> JoinedSequence<Self>
        }

There are many flatten() methods (`where` clauses omitted for brevity):

        extension Sequence {
          func flatten() -> FlattenSequence<Self>
        }

        extension LazySequenceProtocol {
          func flatten() -> LazySequence<FlattenSequence<Self.Elements>>
        }

        extension LazyCollectionProtocol {
          func flatten() -> LazyCollection<FlattenCollection<Self.Elements>>
        }

        extension Collection {
          func flatten() -> FlattenCollection<Self>
        }

        extension BidirectionalCollection {
          func flatten() -> FlattenBidirectionalCollection<Self>
        }

So it's not a simple one-to-one rename.

When there's no `separator` argument, will FlattenIterator perform better than JoinedIterator?

>> And what would happen to the flatMap() methods? Is flatten() a term of art?
>>
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift&gt;
>
> I'd say flatMap is more a "term of art" than flatten. "flatten" just describes literally what is being done. Frankly I'm surprised it was never named flattened(). Anyway, flatMap should stay.

## Future directions

Will the flatMap(_:) methods also have flatMap(separator:_:) variants?

That's an interesting idea. It seems to be purely additive, however, so I imagine it wouldn't happen until after Swift 3.

-- Ben

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

7

Here is a quick example that we would loose.

[["hey"], ["what"]].flatten().joined(separator: “")

[["hey"], ["what"]].flatten() // ["hey", "what”]

The way I think of it is flatten works on array of arrays while joined works on arrays of strings.

I guess we could do this too

[["hey"], ["what"]].joined(separator: ).joined(separator: "")

···

On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

-1 for this. To me there needs to be a difference between String (which is not a normal collection) and other regular collections.

In addition, I really don’t think this proposal has the needed strong support for the change.

On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Here's a proposal draft. Comments welcome:

https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325

On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington <me@benrimmington.com <mailto:me@benrimmington.com>> wrote:

> On 22 Jul 2016, at 20:43, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
>
>> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington <me@benrimmington.com <mailto:me@benrimmington.com>> wrote:
>>
>>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>>
>>> In the swift-lang Slack channel, a few of us were discussing joined(separator:) and realized that flatten() does almost exactly the same thing.
>>>
>>> Is there interest in renaming flatten() to joined()? Since joined takes a separator that's any Sequence, we can't have a default value for the separator parameter, but we can have a variant of joined() with no arguments.
>>
>> I'd like default separators for the joined() methods.
>>
>> <Issues · apple/swift-issues · GitHub;
>>
>> But renaming flatten() to joined() seems complicated.
>>
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb&gt;
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift&gt;
>
> What makes it seem complicated? At the very least, one could just rename the flatten() function. There might also be an opportunity to combine the two files and delete some code from stdlib.

There's only one joined() method (for a sequence of sequences):

        extension Sequence {
          func joined<Separator: Sequence>(separator: Separator) -> JoinedSequence<Self>
        }

There are many flatten() methods (`where` clauses omitted for brevity):

        extension Sequence {
          func flatten() -> FlattenSequence<Self>
        }

        extension LazySequenceProtocol {
          func flatten() -> LazySequence<FlattenSequence<Self.Elements>>
        }

        extension LazyCollectionProtocol {
          func flatten() -> LazyCollection<FlattenCollection<Self.Elements>>
        }

        extension Collection {
          func flatten() -> FlattenCollection<Self>
        }

        extension BidirectionalCollection {
          func flatten() -> FlattenBidirectionalCollection<Self>
        }

So it's not a simple one-to-one rename.

When there's no `separator` argument, will FlattenIterator perform better than JoinedIterator?

>> And what would happen to the flatMap() methods? Is flatten() a term of art?
>>
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift&gt;
>
> I'd say flatMap is more a "term of art" than flatten. "flatten" just describes literally what is being done. Frankly I'm surprised it was never named flattened(). Anyway, flatMap should stay.

## Future directions

Will the flatMap(_:) methods also have flatMap(separator:_:) variants?

That's an interesting idea. It seems to be purely additive, however, so I imagine it wouldn't happen until after Swift 3.

-- Ben

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

8

The thing is, joined also works on arrays-of-arrays today. The only
difference is that flatten doesn't have a separator.

We wouldn't lose what your example shows — you could do this:

[["hey"], ["what"]].joined().joined(separator: “")

···

On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

Here is a quick example that we would loose.

[["hey"], ["what"]].flatten().joined(separator: “")

[["hey"], ["what"]].flatten() // ["hey", "what”]

The way I think of it is flatten works on array of arrays while joined
works on arrays of strings.

I guess we could do this too

[["hey"], ["what"]].joined(separator: ).joined(separator: "")

On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez <cheyo@masters3d.com> > wrote:

-1 for this. To me there needs to be a difference between String (which is
not a normal collection) and other regular collections.

In addition, I really don’t think this proposal has the needed strong
support for the change.

On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:

Here's a proposal draft. Comments welcome:

https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325

On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington <me@benrimmington.com> > wrote:

> On 22 Jul 2016, at 20:43, Jacob Bandes-Storch <jtbandes@gmail.com> >> wrote:
>
>> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington <me@benrimmington.com> >> wrote:
>>
>>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>>
>>> In the swift-lang Slack channel, a few of us were discussing
joined(separator:) and realized that flatten() does almost exactly the same
thing.
>>>
>>> Is there interest in renaming flatten() to joined()? Since joined
takes a separator that's any Sequence, we can't have a default value for
the separator parameter, but we can have a variant of joined() with no
arguments.
>>
>> I'd like default separators for the joined() methods.
>>
>> <Issues · apple/swift-issues · GitHub;
>>
>> But renaming flatten() to joined() seems complicated.
>>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift&gt;
>
> What makes it seem complicated? At the very least, one could just
rename the flatten() function. There might also be an opportunity to
combine the two files and delete some code from stdlib.

There's only one joined() method (for a sequence of sequences):

        extension Sequence {
          func joined<Separator: Sequence>(separator: Separator) ->
JoinedSequence<Self>
        }

There are many flatten() methods (`where` clauses omitted for brevity):

        extension Sequence {
          func flatten() -> FlattenSequence<Self>
        }

        extension LazySequenceProtocol {
          func flatten() -> LazySequence<FlattenSequence<Self.Elements>>
        }

        extension LazyCollectionProtocol {
          func flatten() ->
LazyCollection<FlattenCollection<Self.Elements>>
        }

        extension Collection {
          func flatten() -> FlattenCollection<Self>
        }

        extension BidirectionalCollection {
          func flatten() -> FlattenBidirectionalCollection<Self>
        }

So it's not a simple one-to-one rename.

When there's no `separator` argument, will FlattenIterator perform better
than JoinedIterator?

>> And what would happen to the flatMap() methods? Is flatten() a term of
art?
>>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
>
>
> I'd say flatMap is more a "term of art" than flatten. "flatten" just
describes literally what is being done. Frankly I'm surprised it was never
named flattened(). Anyway, flatMap should stay.

## Future directions

Will the flatMap(_:) methods also have flatMap(separator:_:) variants?

That's an interesting idea. It seems to be purely additive, however, so I
imagine it wouldn't happen until after Swift 3.

-- Ben

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

9

[["hey"], ["what"]].joined().joined() // proposed

vs

[["hey"], ["what"]].flatten().joined(separator: “”) // now

I do agree that having two way of doing it now seems odd.

[["hey"], ["what"]].joined(separator: ).joined(separator: “”) // now

···

On Jul 24, 2016, at 5:47 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

The thing is, joined also works on arrays-of-arrays today. The only difference is that flatten doesn't have a separator.

We wouldn't lose what your example shows — you could do this:

[["hey"], ["what"]].joined().joined(separator: “")
On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:
Here is a quick example that we would loose.

[["hey"], ["what"]].flatten().joined(separator: “")

[["hey"], ["what"]].flatten() // ["hey", "what”]

The way I think of it is flatten works on array of arrays while joined works on arrays of strings.

I guess we could do this too

[["hey"], ["what"]].joined(separator: ).joined(separator: "")

On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:

-1 for this. To me there needs to be a difference between String (which is not a normal collection) and other regular collections.

In addition, I really don’t think this proposal has the needed strong support for the change.

On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Here's a proposal draft. Comments welcome:

https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325

On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington <me@benrimmington.com <mailto:me@benrimmington.com>> wrote:

> On 22 Jul 2016, at 20:43, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
>
>> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington <me@benrimmington.com <mailto:me@benrimmington.com>> wrote:
>>
>>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>>
>>> In the swift-lang Slack channel, a few of us were discussing joined(separator:) and realized that flatten() does almost exactly the same thing.
>>>
>>> Is there interest in renaming flatten() to joined()? Since joined takes a separator that's any Sequence, we can't have a default value for the separator parameter, but we can have a variant of joined() with no arguments.
>>
>> I'd like default separators for the joined() methods.
>>
>> <Issues · apple/swift-issues · GitHub;
>>
>> But renaming flatten() to joined() seems complicated.
>>
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb&gt;
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift&gt;
>
> What makes it seem complicated? At the very least, one could just rename the flatten() function. There might also be an opportunity to combine the two files and delete some code from stdlib.

There's only one joined() method (for a sequence of sequences):

        extension Sequence {
          func joined<Separator: Sequence>(separator: Separator) -> JoinedSequence<Self>
        }

There are many flatten() methods (`where` clauses omitted for brevity):

        extension Sequence {
          func flatten() -> FlattenSequence<Self>
        }

        extension LazySequenceProtocol {
          func flatten() -> LazySequence<FlattenSequence<Self.Elements>>
        }

        extension LazyCollectionProtocol {
          func flatten() -> LazyCollection<FlattenCollection<Self.Elements>>
        }

        extension Collection {
          func flatten() -> FlattenCollection<Self>
        }

        extension BidirectionalCollection {
          func flatten() -> FlattenBidirectionalCollection<Self>
        }

So it's not a simple one-to-one rename.

When there's no `separator` argument, will FlattenIterator perform better than JoinedIterator?

>> And what would happen to the flatMap() methods? Is flatten() a term of art?
>>
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift&gt;
>
> I'd say flatMap is more a "term of art" than flatten. "flatten" just describes literally what is being done. Frankly I'm surprised it was never named flattened(). Anyway, flatMap should stay.

## Future directions

Will the flatMap(_:) methods also have flatMap(separator:_:) variants?

That's an interesting idea. It seems to be purely additive, however, so I imagine it wouldn't happen until after Swift 3.

-- Ben

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

10

Yep. With my proposed renaming this would work:

[["hey"], ["what"]].joined().joined(separator: “”)

But so would this, if you prefer it:

[["hey"], ["what"]].joined().joined()

···

On Sun, Jul 24, 2016 at 6:06 PM, Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

[["hey"], ["what"]].joined().joined() // proposed

vs

[["hey"], ["what"]].flatten().joined(separator: “”) // now

I do agree that having two way of doing it now seems odd.

[["hey"], ["what"]].joined(separator: ).joined(separator: “”) // now

On Jul 24, 2016, at 5:47 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:

The thing is, joined also works on arrays-of-arrays today. The only
difference is that flatten doesn't have a separator.

We wouldn't lose what your example shows — you could do this:

[["hey"], ["what"]].joined().joined(separator: “")
On Sun, Jul 24, 2016 at 5:45 PM Jose Cheyo Jimenez <cheyo@masters3d.com> > wrote:

Here is a quick example that we would loose.

[["hey"], ["what"]].flatten().joined(separator: “")

[["hey"], ["what"]].flatten() // ["hey", "what”]

The way I think of it is flatten works on array of arrays while joined
works on arrays of strings.

I guess we could do this too

[["hey"], ["what"]].joined(separator: ).joined(separator: "")

On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez <cheyo@masters3d.com> >> wrote:

-1 for this. To me there needs to be a difference between String (which
is not a normal collection) and other regular collections.

In addition, I really don’t think this proposal has the needed strong
support for the change.

On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via swift-evolution < >> swift-evolution@swift.org> wrote:

Here's a proposal draft. Comments welcome:

https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325

On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington <me@benrimmington.com> >> wrote:

> On 22 Jul 2016, at 20:43, Jacob Bandes-Storch <jtbandes@gmail.com> >>> wrote:
>
>> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington <me@benrimmington.com> >>> wrote:
>>
>>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote:
>>>
>>> In the swift-lang Slack channel, a few of us were discussing
joined(separator:) and realized that flatten() does almost exactly the same
thing.
>>>
>>> Is there interest in renaming flatten() to joined()? Since joined
takes a separator that's any Sequence, we can't have a default value for
the separator parameter, but we can have a variant of joined() with no
arguments.
>>
>> I'd like default separators for the joined() methods.
>>
>> <Issues · apple/swift-issues · GitHub;
>>
>> But renaming flatten() to joined() seems complicated.
>>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/Flatten.swift.gyb
>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/Join.swift
>
>
> What makes it seem complicated? At the very least, one could just
rename the flatten() function. There might also be an opportunity to
combine the two files and delete some code from stdlib.

There's only one joined() method (for a sequence of sequences):

        extension Sequence {
          func joined<Separator: Sequence>(separator: Separator) ->
JoinedSequence<Self>
        }

There are many flatten() methods (`where` clauses omitted for brevity):

        extension Sequence {
          func flatten() -> FlattenSequence<Self>
        }

        extension LazySequenceProtocol {
          func flatten() -> LazySequence<FlattenSequence<Self.Elements>>
        }

        extension LazyCollectionProtocol {
          func flatten() ->
LazyCollection<FlattenCollection<Self.Elements>>
        }

        extension Collection {
          func flatten() -> FlattenCollection<Self>
        }

        extension BidirectionalCollection {
          func flatten() -> FlattenBidirectionalCollection<Self>
        }

So it's not a simple one-to-one rename.

When there's no `separator` argument, will FlattenIterator perform
better than JoinedIterator?

>> And what would happen to the flatMap() methods? Is flatten() a term
of art?
>>
>> <
https://github.com/apple/swift/blob/master/stdlib/public/core/FlatMap.swift
>
>
> I'd say flatMap is more a "term of art" than flatten. "flatten" just
describes literally what is being done. Frankly I'm surprised it was never
named flattened(). Anyway, flatMap should stay.

## Future directions

Will the flatMap(_:) methods also have flatMap(separator:_:) variants?

That's an interesting idea. It seems to be purely additive, however, so I
imagine it wouldn't happen until after Swift 3.

-- Ben

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