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?
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])
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)
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?
Cheers,
Paul
> On Jul 12, 2016, at 1:12 PM, Chris Lattner <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution