[swift-evolution] [swift-evolution-announce] [Review] SE-0120: Revise 'partition' Method Signature
cantrell at pobox.com
Wed Jul 13 00:07:04 CDT 2016
> On Jul 12, 2016, at 7:27 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> on Tue Jul 12 2016, Paul Cantrell <swift-evolution at swift.org> wrote:
>> Does this proposal leave room for the two-collection variant if we
>> want to add it later?
>> 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
> I don't see any such overloading here.
These two methods differ only by return type:
mutating func partitioned(by: …) -> ([Self.Iterator.Element], [Self.Iterator.Element])
mutating func partitioned(by: …) -> ([Self.Iterator.Element], Index)
These are the two methods a hypothetical post-3.0 stdlib would end up with given two fairly reasonable assumptions:
1. that we’d like a non-mutating variant of the “partition” method proposed here, and
2. that we’d like the stdlib to provide the two-collection “partition” as well.
To be clear, I’m _not_ proposing adding either of those things now. I’m only wondering whether using the name “partition” for the method under discussion now paints us into a corner later.
>> 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.
Right, we’d be in the clear if that were the _only_ non-mutating counterpart of “partition,” i.e. if we only had this method:
mutating func partitioned(by: …) -> (ArraySlice<Self.Iterator.Element>, ArraySlice<Self.Iterator.Element>)
…instead of the two I listed above.
And this slice variant does seem to provide all the advantages of both the two above, so I think it could be the only “partitioned” method. My concern is thus addressed. Thanks.
More information about the swift-evolution