[Accepted] SE-0133: Rename flatten() to joined()


(Chris Lattner) #1

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

The review of "SE-0133: Rename flatten() to joined()" ran from Active review July 24…26. The proposal has been *accepted*.

This proposal had significant positive community feedback for aligning common operation names, but raised questions about whether ‘flatten’ was term of art, and what it would mean for related operations like ‘flatMap’. The core team discussed both sides of this debate, and decided it is best to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve its term of art. The core team prefers that it remain a distinct overload of joined(separator:) to preserve performance. It also requests that the returned collection types (FlattenCollection and friends) be left as-is for now, since they are not names commonly directly referenced, and we’d like to keep the change minimal.

Thank you to Jacob Bandes-Storch for driving this discussion forward! Time is short, we’d appreciate it if someone could implement this ASAP.

-Chris Lattner
Review Manager


(Jacob Bandes-Storch) #2

I'll get right on it. Thanks to everyone who provided great feedback
during the review!

···

On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

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

The review of "SE-0133: Rename flatten() to joined()" ran from Active
review July 24…26. The proposal has been *accepted*.

This proposal had significant positive community feedback for aligning
common operation names, but raised questions about whether ‘flatten’ was
term of art, and what it would mean for related operations like ‘flatMap’.
The core team discussed both sides of this debate, and decided it is best
to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve
its term of art. The core team prefers that it remain a distinct overload
of joined(separator:) to preserve performance. It also requests that the
returned collection types (FlattenCollection and friends) be left as-is for
now, since they are not names commonly directly referenced, and we’d like
to keep the change minimal.

Thank you to Jacob Bandes-Storch for driving this discussion forward!
Time is short, we’d appreciate it if someone could implement this ASAP.

-Chris Lattner
Review Manager

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


(Jacob Bandes-Storch) #3

Does the core team have feedback on whether Collection<String>'s
joined(separator:) should have a default separator of "", or another
overload with no parameter?

···

On Wed, Jul 27, 2016 at 2:56 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

I'll get right on it. Thanks to everyone who provided great feedback
during the review!

On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

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

The review of "SE-0133: Rename flatten() to joined()" ran from Active
review July 24…26. The proposal has been *accepted*.

This proposal had significant positive community feedback for aligning
common operation names, but raised questions about whether ‘flatten’ was
term of art, and what it would mean for related operations like ‘flatMap’.
The core team discussed both sides of this debate, and decided it is best
to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve
its term of art. The core team prefers that it remain a distinct overload
of joined(separator:) to preserve performance. It also requests that the
returned collection types (FlattenCollection and friends) be left as-is for
now, since they are not names commonly directly referenced, and we’d like
to keep the change minimal.

Thank you to Jacob Bandes-Storch for driving this discussion forward!
Time is short, we’d appreciate it if someone could implement this ASAP.

-Chris Lattner
Review Manager

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


(Chris Lattner) #4

Does the core team have feedback on whether Collection<String>'s joined(separator:) should have a default separator of "", or another overload with no parameter?

"The core team prefers that it remain a distinct overload of joined(separator:) to preserve performance.” :-)

Thanks Jacob!

-Chris

···

On Jul 27, 2016, at 2:59 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

On Wed, Jul 27, 2016 at 2:56 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
I'll get right on it. Thanks to everyone who provided great feedback during the review!

On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md

The review of "SE-0133: Rename flatten() to joined()" ran from Active review July 24…26. The proposal has been *accepted*.

This proposal had significant positive community feedback for aligning common operation names, but raised questions about whether ‘flatten’ was term of art, and what it would mean for related operations like ‘flatMap’. The core team discussed both sides of this debate, and decided it is best to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve its term of art. The core team prefers that it remain a distinct overload of joined(separator:) to preserve performance. It also requests that the returned collection types (FlattenCollection and friends) be left as-is for now, since they are not names commonly directly referenced, and we’d like to keep the change minimal.

Thank you to Jacob Bandes-Storch for driving this discussion forward! Time is short, we’d appreciate it if someone could implement this ASAP.

-Chris Lattner
Review Manager

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


(Jacob Bandes-Storch) #5

I figured that sentence was in reference to the methods currently named
flatten().

The proposal also said that the String-based version of joined(separator:)
(which are implemented separately) should have a default separator of "".
There is currently no flatten() for collections of Strings.

https://github.com/apple/swift/blob/c6e828f761fc30f7ce444431de7da52814f96595/stdlib/public/core/String.swift#L769

I doubt there would be a performance difference between adding `func
joined() { return joined(separator: "") }` and changing the parameter to
`separator: String = ""`.

Jacob

···

On Wed, Jul 27, 2016 at 3:57 PM, Chris Lattner <clattner@apple.com> wrote:

On Jul 27, 2016, at 2:59 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:

Does the core team have feedback on whether Collection<String>'s
joined(separator:) should have a default separator of "", or another
overload with no parameter?

"The core team prefers that it remain a distinct overload of
joined(separator:) to preserve performance.” :slight_smile:

Thanks Jacob!

-Chris

On Wed, Jul 27, 2016 at 2:56 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:

I'll get right on it. Thanks to everyone who provided great feedback
during the review!

On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote:

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

The review of "SE-0133: Rename flatten() to joined()" ran from Active
review July 24…26. The proposal has been *accepted*.

This proposal had significant positive community feedback for aligning
common operation names, but raised questions about whether ‘flatten’ was
term of art, and what it would mean for related operations like ‘flatMap’.
The core team discussed both sides of this debate, and decided it is best
to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve
its term of art. The core team prefers that it remain a distinct overload
of joined(separator:) to preserve performance. It also requests that the
returned collection types (FlattenCollection and friends) be left as-is for
now, since they are not names commonly directly referenced, and we’d like
to keep the change minimal.

Thank you to Jacob Bandes-Storch for driving this discussion forward!
Time is short, we’d appreciate it if someone could implement this ASAP.

-Chris Lattner
Review Manager

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


(Chris Lattner) #6

I’ll let a stdlib guru comment on this :-)

-Chris

···

On Jul 27, 2016, at 4:00 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

I figured that sentence was in reference to the methods currently named flatten().

The proposal also said that the String-based version of joined(separator:) (which are implemented separately) should have a default separator of "". There is currently no flatten() for collections of Strings.

https://github.com/apple/swift/blob/c6e828f761fc30f7ce444431de7da52814f96595/stdlib/public/core/String.swift#L769

I doubt there would be a performance difference between adding `func joined() { return joined(separator: "") }` and changing the parameter to `separator: String = "”`.


(Paulo Faria) #7

I doubt there would be a performance difference between adding `func joined() { return joined(separator: "") }` and changing the parameter to `separator: String = "”`.

I’ll let a stdlib guru comment on this :slight_smile:

I’m very curious about this. Default parameters are really slower?


(John McCall) #8

The version that takes an arbitrary separator as a parameter (defaulted or not) does twice as many appends unless it specifically recognizes the empty separator as a special case.

That said, I'm not sure it shouldn't try to recognize the empty separator as a special case.

John.

···

On Jul 28, 2016, at 6:38 AM, Paulo Faria via swift-evolution <swift-evolution@swift.org> wrote:

I doubt there would be a performance difference between adding `func joined() { return joined(separator: "") }` and changing the parameter to `separator: String = "”`.

I’ll let a stdlib guru comment on this :slight_smile:

I’m very curious about this. Default parameters are really slower?


(Rod Brown) #9

This makes perfect sense why it would perform worse, and I agree this seems like a legitimate place for a special case.

···

On 29 Jul 2016, at 3:01 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 28, 2016, at 6:38 AM, Paulo Faria via swift-evolution <swift-evolution@swift.org> wrote:

I doubt there would be a performance difference between adding `func joined() { return joined(separator: "") }` and changing the parameter to `separator: String = "”`.

I’ll let a stdlib guru comment on this :slight_smile:

I’m very curious about this. Default parameters are really slower?

The version that takes an arbitrary separator as a parameter (defaulted or not) does twice as many appends unless it specifically recognizes the empty separator as a special case.

That said, I'm not sure it shouldn't try to recognize the empty separator as a special case.

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