+1 — Proposal looks fantastic. It’s very clear and intuitive. Thanks for listening to our feedback! **Patrick Smith**
On Apr 27 2016, at 7:50 am, Dave Abrahams via swift-evolution <swift- [email protected]> wrote: > on Tue Apr 26 2016, Haravikk <[email protected]> wrote: > > > I prefer the index() method name for this purpose, but I wonder if we might want > to consider overloads for forward/backward, since not all indexes are > bidirectional (or at least, not efficiently so), for example: > > index(_ index:Index, advancedBy:Index.Distance) -> Index > index(_ index:Index, reversedBy:Index.Distance) -> Index // Only declared where > Self.Index : BidirectionalIndexType? > > But yeah, everything related to index manipulation should be doable from some > variant of .index() I think. > > I agree and have updated the proposal accordingly. > > https://github.com/apple/swift-evolution/blob/master/proposals/0065 -collections-move-indices.md > > > > On 26 Apr 2016, at 08:49, Patrick Smith via swift-evolution > <[email protected]> wrote: > > Yes, I too find the naming confusing. I think the method should contain > 'index', either in the prefix or as a parameter label, so if you searched > through Collection’s methods you’d be able to find every one that was to do > with indexes. > > Sorry to suggest more ideas, but here is a theoretical API with index in the > prefix: (the noun is ‘index’) > > func index(_ index: Index, offsetBy n: IndexDistance) -> Index > > func index(_ index: Index, offsetBy n: IndexDistance, limitedBy limit: > Index) -> Index > > func formIndex(_ index: inout Index, offsetBy n: IndexDistance) > > func formIndex(_ index: inout Index, offsetBy n: IndexDistance, limitedBy > limit: Index) > > And here is one within a parameter: (the verb is ‘offset’) > > func offsetted(index: Index, by n: IndexDistance) -> Index > > func offsetted(index: Index, by n: IndexDistance, limitedBy limit: Index) -> > Index > > func offset(index: inout Index, offsetBy n: IndexDistance) > > func offset(index: inout Index, offsetBy n: IndexDistance, limitedBy limit: > Index) > > Patrick Smith > > On Apr 26 2016, at 11:52 am, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > On Mon, Apr 25, 2016 at 8:25 PM, Dave Abrahams <[email protected]> > wrote: > > on Mon Apr 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> 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? > > My mistake; I pushed to the wrong repo. Please try again. > > I see a new version, but I still see .successor(). > > > 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". 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) > > As I've said before, the “ing” suffix strongly implies we're > returning > (a version of) `c`, not of `i`. c.f. > > Please hand me **your coat, emptying the left pocket**. > > You're not going to get a pocket; you're getting a whole coat. > > Quite right; didn't mean to retread that. I feel the same deficiency > applies to using the "form" convention, though, in that (at least as has > been discussed on this list) the convention usually refers to the > receiver being mutated. Thus, `c.formLocation(...)` sounds like `c` > should be mutated in some way. > > One way out that I can think of is looking to good ol' Objective-C > conventions. By this I mean that, in my mind, shorter method names like > `str.appending(...)` are derived by omitting redundant words from longer > ancestral names such as `str.stringByAppendingString(...)`. In this > particular case, certain words are not redundant and perhaps we should > just bravely put back those words that are necessary to clarify. > > That is, if this were Objective-C, we'd have something like > "indexByAdvancingIndex". You're quite right that we can't use just > "advancing" because it implies returning a version of the receiver. > We've tried "index", but then it conflicts with another method "index". > Now there's renaming "index" to "location", even though it returns a > thing of type Index... Aren't the most succinct but still accurate > method names instead: `c.indexByAdvancing(i, ...)` and `c.advanceIndex > (&i, ...)`? [Incidentally, `c.advance` might read like c is being > advanced.] > > > 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.") > > the limit label is the least of my concerns here :-) > > That said, orthogonally, I feel like many `limitedBy` labels can be > simplified to `limit` :) > > > > 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 > > > > \-- > Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > Thanks! > > \-- Dave > > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
