<head></head><body>+1 — Proposal looks fantastic. It’s very clear and intuitive. Thanks for listening to our feedback!<br><br><!-- <signature> --><b>Patrick Smith</b><br><!-- </signature> --><div class="gmail_quote">
On Apr 27 2016, at 7:50 am, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p>on Tue Apr 26 2016, Haravikk <swift-evolution@swift.org> wrote:</p>
<p>> I prefer the index() method name for this purpose, but I wonder if we might want<br>> to consider overloads for forward/backward, since not all indexes are<br>> bidirectional (or at least, not efficiently so), for example:<br>><br>> index(_ index:Index, advancedBy:Index.Distance) -> Index<br>> index(_ index:Index, reversedBy:Index.Distance) -> Index // Only declared where<br>> Self.Index : BidirectionalIndexType?<br>><br>> But yeah, everything related to index manipulation should be doable from some<br>> variant of .index() I think.</p>
<p>I agree and have updated the proposal accordingly.</p>
<p>https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md</p>
<p>><br>> On 26 Apr 2016, at 08:49, Patrick Smith via swift-evolution<br>> <swift-evolution@swift.org> wrote:<br>><br>> Yes, I too find the naming confusing. I think the method should contain<br>> 'index', either in the prefix or as a parameter label, so if you searched<br>> through Collection’s methods you’d be able to find every one that was to do<br>> with indexes.<br>><br>> Sorry to suggest more ideas, but here is a theoretical API with index in the<br>> prefix: (the noun is ‘index’)<br>><br>> func index(_ index: Index, offsetBy n: IndexDistance) -> Index<br>><br>> func index(_ index: Index, offsetBy n: IndexDistance, limitedBy limit:<br>> Index) -> Index<br>><br>> func formIndex(_ index: inout Index, offsetBy n: IndexDistance)<br>><br>> func formIndex(_ index: inout Index, offsetBy n: IndexDistance, limitedBy<br>> limit: Index)<br>><br>> And here is one within a parameter: (the verb is ‘offset’)<br>><br>> func offsetted(index: Index, by n: IndexDistance) -> Index<br>><br>> func offsetted(index: Index, by n: IndexDistance, limitedBy limit: Index) -><br>> Index<br>><br>> func offset(index: inout Index, offsetBy n: IndexDistance)<br>><br>> func offset(index: inout Index, offsetBy n: IndexDistance, limitedBy limit:<br>> Index)<br>><br>> Patrick Smith<br>><br>> On Apr 26 2016, at 11:52 am, Xiaodi Wu via swift-evolution<br>> <swift-evolution@swift.org> wrote: <br>><br>> On Mon, Apr 25, 2016 at 8:25 PM, Dave Abrahams <dabrahams@apple.com><br>> wrote:<br>><br>> on Mon Apr 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:<br>><br>> > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams<br>> <dabrahams@apple.com> wrote:<br>> ><br>> > on Mon Apr 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:<br>> ><br>> > > Quick thought:<br>> > ><br>> > > Why are you reaching for the "form..." rule for the mutating<br>> methods when<br>> > there<br>> > > are clear verb counterparts?<br>> > > location: locate<br>> > > successor: succeed<br>> ><br>> > We're not using successor(i) anymore, as noted below, and<br>> furthermore<br>> > c.succeed(&i) strongly implies the wrong meaning.<br>> ><br>> > I thought that's what I understood from the email, but in the<br>> linked proposal<br>> > they're still there (as are the many types of Range protocols).<br>> Wrong link, or<br>> > just not updated?<br>><br>> My mistake; I pushed to the wrong repo. Please try again.<br>><br>> I see a new version, but I still see .successor().<br>><br>> > I didn't consider<br>> > using<br>> ><br>> > c. locate(...:&i ... )<br>> ><br>> > primarily because I never thought of it and nobody suggested it<br>> IIRC,<br>> > but I also don't see how it would work in a family with<br>> > c.location(after: i) et al. Suggestions?<br>> ><br>> > I didn't read this proposal carefully on its initial presentation<br>> for review.<br>> > Looking at it now, I wonder about the wisdom of "location"--I<br>> understand the<br>> > rationale of avoiding multiple methods named "index" that do<br>> different things,<br>> > but these particular functions return or mutate indices, and<br>> nowhere else are<br>> > these called "locations". If you're asking for possible<br>> alternative suggestions<br>> > to avoid using "index", I'll suggest the following here because I<br>> don't recall<br>> > seeing them offered previously. They read as phrases or sentences:<br>> ><br>> > ```<br>> > // taking inspiration from ForwardIndexType, which is no more...<br>> > c.advancing(_ i: Index, by offset: IndexDistance, limit: Index)<br>><br>> As I've said before, the “ing” suffix strongly implies we're<br>> returning<br>> (a version of) `c`, not of `i`. c.f.<br>><br>> Please hand me **your coat, emptying the left pocket**.<br>><br>> You're not going to get a pocket; you're getting a whole coat.<br>><br>> Quite right; didn't mean to retread that. I feel the same deficiency<br>> applies to using the "form" convention, though, in that (at least as has<br>> been discussed on this list) the convention usually refers to the<br>> receiver being mutated. Thus, `c.formLocation(...)` sounds like `c`<br>> should be mutated in some way.<br>><br>> One way out that I can think of is looking to good ol' Objective-C<br>> conventions. By this I mean that, in my mind, shorter method names like<br>> `str.appending(...)` are derived by omitting redundant words from longer<br>> ancestral names such as `str.stringByAppendingString(...)`. In this<br>> particular case, certain words are not redundant and perhaps we should<br>> just bravely put back those words that are necessary to clarify.<br>><br>> That is, if this were Objective-C, we'd have something like<br>> "indexByAdvancingIndex". You're quite right that we can't use just<br>> "advancing" because it implies returning a version of the receiver.<br>> We've tried "index", but then it conflicts with another method "index".<br>> Now there's renaming "index" to "location", even though it returns a<br>> thing of type Index... Aren't the most succinct but still accurate<br>> method names instead: `c.indexByAdvancing(i, ...)` and `c.advanceIndex<br>> (&i, ...)`? [Incidentally, `c.advance` might read like c is being<br>> advanced.]<br>><br>> > c.advance(_ i: inout Index, by offset: IndexDistance, limit:<br>> Index)<br>> ><br>> > // or alternatively, using the terminology in the comments that<br>> sit above<br>> > `location`<br>> > c.offsetting(_ i: Index, by n: IndexDistance, limit: Index)<br>> > c.offset(_ i: inout Index, by n: IndexDistance, limit: Index)<br>> ><br>> > // and then, in place of successor, etc.<br>> > c.incrementing(_ i: Index, limit: Index)<br>> > c.increment(_ i: inout Index, limit: Index)<br>> > c.decrementing(_ i: Index, limit: Index)<br>> > c.decrement(_ i: inout Index, limit: Index)<br>> > ```<br>> > ("'Limit' doesn't read like a phrase," you might say. Well, think<br>> of a coupon:<br>> > "$1 off one tub of margarine. Limit one per purchase. Void if<br>> transferred or<br>> > sold.")<br>><br>> the limit label is the least of my concerns here :-)<br>><br>> That said, orthogonally, I feel like many `limitedBy` labels can be<br>> simplified to `limit` :)<br>><br>> > > On Mon, Apr 25, 2016 at 1:24 PM, Dave Abrahams via<br>> swift-evolution<br>> > > <swift-evolution@swift.org> wrote:<br>> > ><br>> > > on Wed Apr 20 2016, Chris Lattner<br>> <swift-evolution@swift.org> wrote:<br>> > ><br>> > > > On Apr 10, 2016, at 2:41 PM, Chris Lattner<br>> > > > <clattner@apple.com> wrote:<br>> > > ><br>> > > > Hello Swift community,<br>> > > ><br>> > > > The review of "A New Model for Collections and Indices" begins<br>> now and<br>> > > runs<br>> > > > through April 18th. The proposal is available here:<br>> > > ><br>> > > ><br>> > ><br>> ><br>> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md<br>><br>> ><br>> > ><br>> > > ><br>> > > > Reviews are an important part of the Swift evolution process.<br>> All<br>> > reviews<br>> > > > should be sent to the swift-evolution mailing list at:<br>> > > > https://lists.swift.org/mailman/listinfo/swift-evolution<br>> > > > or, if you would like to keep your feedback private, directly<br>> to the<br>> > > review<br>> > > > manager.<br>> > > ><br>> > > > A quick update: the core team met to discuss this. They agreed<br>> to accept<br>> > > it with<br>> > > > some naming-related revisions to the proposal (in response to<br>> community<br>> > > > feedback). Dave is organizing this feedback, and I’ll send out<br>> the<br>> > formal<br>> > > > announcement when that is ready.<br>> > ><br>> > > The final revisions are reflected in the latest version of the<br>> > > proposal:<br>> > ><br>> > ><br>> ><br>> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md<br>><br>> ><br>> > ><br>> > > Summary:<br>> > ><br>> > > * We decided to take Shawn Erickson's excellent suggestion<br>> > > <http://article.gmane.org/gmane.comp.lang.swift.evolution/14450><br>> to<br>> > > use “location” uniformly for index movement, so instead of<br>> > > successor(i) and predecessor(i) we have location(after: i) and<br>> > > location(before: i).<br>> > ><br>> > > * Since Brent Royal-Gordon pointed out<br>> > ><br>> ><br>> <http://news.gmane.org/find-root.php?message_id=156D8FB1%2d1FD3%2d448E%2d8C70%2d6E7400629BC0%40architechies.com<br>><br>> ><br>> > > ><br>> > > that two of the three proposed Range protocols would likely<br>> disappear<br>> > > in future updates, we took another look at all of them. Finding<br>> > > `RangeProtocol` itself to be a very weak abstraction, we removed<br>> all<br>> > > three from the proposal.<br>> > ><br>> > > For those interested in details, implementation work proceeds<br>> apace on<br>> > > the swift-3-indexing-model branch at<br>> > ><br>> ><br>> <https://github.com/apple/swift/tree/swift-3-indexing-model/stdlib/public/core<br>><br>> ><br>> > > >.<br>> > ><br>> > > P.S. If anyone is interested in contributing, there are still<br>> plenty of<br>> > > FIXMEs left for us to handle ;-)<br>> > ><br>> > > --<br>> > > Dave<br>> > ><br>> > > _______________________________________________<br>> > > swift-evolution mailing list<br>> > > swift-evolution@swift.org<br>> > > https://lists.swift.org/mailman/listinfo/swift-evolution<br>> > ><br>> ><br>> > --<br>> > Dave<br>> ><br>><br>> --<br>> Dave<br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org<br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>><br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org<br>> https://lists.swift.org/mailman/listinfo/swift-evolution</p>
<p>Thanks!</p>
<p>-- <br>Dave</p>
<p>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution</p>
</blockquote>
</div></body>