[swift-evolution] [swift-evolution-announce] [Review] SE-0120: Revise 'partition' Method Signature

[Dave Abrahams]

on Tue Jul 12 2016, Paul Cantrell <swift-evolution at swift.org> wrote:

> The proposal is clearly an improvement over the status quo.
>
> A naming concern, which I apologize for not getting in before the review period:
>
> In Ruby (and I think some other languages as well), “partition”
> returns two collections, one with the included elements and one with
> the excluded. That’s a useful flavor of the method to have. I’ve added
> it in an extension myself in a project or two.
>
> Does this proposal leave room for the two-collection variant if we
> want to add it later?

Yes.

  let p = x.partition { ... }
  excluded = x[x.startIndex..<p]
  included = x[p..<x.endIndex]

> If it were to honor the existing term of art, the natural name for it would be “partitioned(by:)”:
>
>     mutating func partitioned(by: …) -> ([Self.Iterator.Element], [Self.Iterator.Element])

Yes, we are interested in more algorithms,
but they are out-of-scope for Swift 3.  

> However, naming the in-place reordering method “partition” as this
> proposal does would suggest instead that “partitioned(by:)” is instead
> its non-mutating counterpart:
>
>     mutating func partitioned(by: …) -> ([Self.Iterator.Element], Index)

Yes a non-mutating one.  The above might return.
a pair of ArraySlice, with some way to retrieve the underlying Array.

> Overloading on return type is dicey business, especially when the type
> resolver has to peer inside a tuple. Could these two flavors coexist
> peacefully? Will this be confusing? Are we painting ourselves into a
> corner?

I don't see any such overloading here.

> Cheers,
>
> Paul
>
>> On Jul 12, 2016, at 1:12 PM, Chris Lattner <clattner at apple.com> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0120: Revise ‘partition' Method Signature" begins now and runs through July 19. The proposal is available here:
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.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-announce mailing list
>> swift-evolution-announce at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave