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