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

[Paul Cantrell]

> 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
>> corner?
> 
> 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.

But…

>>   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.

Cheers,

Paul