on Mon Apr 25 2016, Xiaodi Wu <[email protected]> wrote: > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams > <[email protected]> wrote: > > on Mon Apr 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: > > > Quick thought: > > > > Why are you reaching for the "form..." rule for the mutating methods > when > there > > are clear verb counterparts? > > location: locate > > successor: succeed > > We're not using successor(i) anymore, as noted below, and furthermore > c.succeed(&i) strongly implies the wrong meaning. > > I thought that's what I understood from the email, but in the linked proposal > they're still there (as are the many types of Range protocols). Wrong link, or > just not updated?
Gah! https://github.com/apple/swift-evolution/commit/6cd17c941303518699f4631dc71b6286c05b35b0 > I didn't consider > using > > c. locate(...:&i ... ) > > primarily because I never thought of it and nobody suggested it IIRC, > but I also don't see how it would work in a family with > c.location(after: i) et al. Suggestions? > > I didn't read this proposal carefully on its initial presentation for review. > Looking at it now, I wonder about the wisdom of "location"--I understand the > rationale of avoiding multiple methods named "index" that do different things, > but these particular functions return or mutate indices, and nowhere else are > these called "locations". And I found this quite compelling, so after some discussion here I have gone from “location” back to “index” everywhere. https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > If you're asking for possible alternative suggestions to avoid using > "index", I'll suggest the following here because I don't recall seeing > them offered previously. They read as phrases or sentences: > > ``` > // taking inspiration from ForwardIndexType, which is no more... > c.advancing(_ i: Index, by offset: IndexDistance, limit: Index) > c.advance(_ i: inout Index, by offset: IndexDistance, limit: Index) > > // or alternatively, using the terminology in the comments that sit above > `location` > c.offsetting(_ i: Index, by n: IndexDistance, limit: Index) > c.offset(_ i: inout Index, by n: IndexDistance, limit: Index) > > // and then, in place of successor, etc. > c.incrementing(_ i: Index, limit: Index) > c.increment(_ i: inout Index, limit: Index) > c.decrementing(_ i: Index, limit: Index) > c.decrement(_ i: inout Index, limit: Index) > ``` > ("'Limit' doesn't read like a phrase," you might say. Well, think of a coupon: > "$1 off one tub of margarine. Limit one per purchase. Void if transferred or > sold.") > > > On Mon, Apr 25, 2016 at 1:24 PM, Dave Abrahams via swift-evolution > > <[email protected]> wrote: > > > > on Wed Apr 20 2016, Chris Lattner > <[email protected]> wrote: > > > > > On Apr 10, 2016, at 2:41 PM, Chris Lattner > > > <[email protected]> wrote: > > > > > > Hello Swift community, > > > > > > The review of "A New Model for Collections and Indices" begins now and > > runs > > > through April 18th. The proposal is available here: > > > > > > > > > > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > > > > > > > > Reviews are an important part of the Swift evolution process. All > reviews > > > should be sent to the swift-evolution mailing list at: > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > or, if you would like to keep your feedback private, directly to the > > review > > > manager. > > > > > > A quick update: the core team met to discuss this. They agreed to > accept > > it with > > > some naming-related revisions to the proposal (in response to > community > > > feedback). Dave is organizing this feedback, and I’ll send out the > formal > > > announcement when that is ready. > > > > The final revisions are reflected in the latest version of the > > proposal: > > > > > > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > > > > Summary: > > > > * We decided to take Shawn Erickson's excellent suggestion > > <http://article.gmane.org/gmane.comp.lang.swift.evolution/14450> to > > use “location” uniformly for index movement, so instead of > > successor(i) and predecessor(i) we have location(after: i) and > > location(before: i). > > > > * Since Brent Royal-Gordon pointed out > > > > <http://news.gmane.org/find-root.php?message_id=156D8FB1%2d1FD3%2d448E%2d8C70%2d6E7400629BC0%40architechies.com > > > > > > that two of the three proposed Range protocols would likely disappear > > in future updates, we took another look at all of them. Finding > > `RangeProtocol` itself to be a very weak abstraction, we removed all > > three from the proposal. > > > > For those interested in details, implementation work proceeds apace on > > the swift-3-indexing-model branch at > > > > <https://github.com/apple/swift/tree/swift-3-indexing-model/stdlib/public/core > > > >. > > > > P.S. If anyone is interested in contributing, there are still plenty of > > FIXMEs left for us to handle ;-) > > > > -- > > Dave > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > -- > Dave > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
