> On May 11, 2016, at 12:32 PM, Hooman Mehr via swift-evolution
> <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
