[swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

[Nate Cook]

> On May 11, 2016, at 12:32 PM, Hooman Mehr via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Thank you for your comments. 
> 
> I think additional index manipulation and collection scanning API is needed, and your proposal cover an important part of it.
> 
> I also have some clarifications and comments inline:
> 
>>> On May 10, 2016, at 4:52 PM, Nate Cook <natecook at gmail.com> wrote:
>>> Thanks Hooman! Those do look like useful extensions. I think the proposal should stay focused on the APIs it includes already.
>>> On May 10, 2016, at 4:18 PM, Hooman Mehr <hooman at mac.com> wrote:
>>> public func offset(of index: Index) -> IndexDistance
>>> public func index(atOffset offset: IndexDistance) -> Index
>> 
>> I like these, but I doubt they would get much traction, since they're essentially substituting startIndex into existing methods. I have thought it would be nice to have startIndex as the default parameter to those methods, though, so you could write either of these:
>> 
>> 	let i = c.index(c.startIndex, offsetBy: 5)		// current
>> 	let i = c.index(offsetBy: 5)				// nice addition
> 
> That is right. The main function is `offset` that I use a lot and for the reverse, your suggestion seems better. I am using `offset` quite a bit but I don’t know if it is generally as useful for other people as it is for me.

'distance(from:to:)' is the corresponding method to your 'offset(of:)', although it might need a different name if the first parameter were optional. I don't find it onerous to provide c.startIndex when using that one.

>>> public func index(of element: Iterator.Element, from firstIndex: Index) -> Index?
>>> public func index(from firstIndex: Index, where predicate: @noescape (Iterator.Element) throws -> Bool) rethrows -> Index?
>> 
>> I have the same reaction to these. Because indices are shared between collections and slices, instead of using a starting index, Swift's collection operations can just work on a slice. So instead of calling
>> 
>> 	let i = c.index(of: "A", from: firstIndex)
>> 
>> you can call
>> 
>> 	let i = c.suffix(from: firstIndex).index(of: "A”)
> 
> The point is: The `i` above is an index into the (discarded) slice returned by `suffix()`, not the collection `c`. In general, it does not work correctly on the original collection. The behavior of slice indexes have changed a couple of times and is not totally consistent or guaranteed for different concrete collections. That is the reason I am proposing the above function to provide a sure way to have this functionality working properly and I find it extremely useful. Again I don’t know about others.
> 
> It seems that the subject of the interaction between slice indexes and the parent collections need further clarifications and specification from the core Swift team.

Indices from slices absolutely should reference the same element(s) in the original collection―the collections system is based in part on that interoperability. If you see any behavior that deviates from this, please file a bug!

>>> public func index<C: Collection where ...>(of elementSequence: C) -> Index?
>>> public func index<C: Collection where ...>(of elementSequence: C, from firstIndex: Index) -> Index?
>> 
>> These methods we don't have at all currently, and could really use! I would definitely support a proposal for finding a subsequence of a collection. There are several algorithms beyond the naive approach, so it would be interesting to see if / how a proposal could use those in a generic context.
> 
> I updated the gist. Besides some corrections and removing a couple of extension constraints, I merged the two functions above into:
> 
> public func index<C: Collection where ...>(of elementSequence: C, from firstIndex: Index? = nil) -> Index?
> 
> I think the basic implementation in the gist is good enough for many cases and we can specialize for array. As long as the collection and the sub-collection are not huge, performance should be fine.
> 
> On the other hand, I am too busy to seriously propose and pursue its addition. If enough people find it worthy of general inclusion into the standard library, somebody will pick it up, but not me.
> 
> I didn’t intend to hijack your proposal, but I thought some comments would help clarify things.
> 
> Thank you again,
> Hooman

Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/047494c9/attachment.html>