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