> On Jul 12, 2016, at 7:27 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > > on Tue Jul 12 2016, Paul Cantrell <swift-evolution@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
