<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>index(_ index:Index, advancedBy:Index.Distance) -> Index</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>index(_ index:Index, reversedBy:Index.Distance) -> Index<span class="Apple-tab-span" style="white-space:pre"> </span>// Only declared where Self.Index : BidirectionalIndexType?</font></div><div class=""><br class=""></div><div class="">But yeah, everything related to index manipulation should be doable from some variant of .index() I think.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 26 Apr 2016, at 08:49, Patrick Smith via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">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.<div class=""><div class=""><br class=""></div><div class="">Sorry to suggest more ideas, but here is a theoretical API with index in the prefix: (the noun is ‘index’)</div><div class=""><div class=""><br class=""></div><div class="">func index(_ index: Index, offsetBy n: IndexDistance) -> Index<br class=""></div><div class="">func index(_ index: Index, offsetBy n: IndexDistance, limitedBy limit: Index) -> Index<br class=""></div><div class=""><br class=""></div><div class="">func formIndex(_ index: inout Index, offsetBy n: IndexDistance)<br class=""></div><div class="">func formIndex(_ index: inout Index, offsetBy n: IndexDistance, limitedBy limit: Index)<br class=""></div><div class=""><br class=""></div><div class="">And here is one within a parameter: (the verb is ‘offset’)</div><div class=""><br class=""></div><div class=""><div style="line-height: 19.6px;" class="">func offsetted(index: Index, by n: IndexDistance) -> Index<br class=""></div><div style="line-height: 19.6px;" class="">func offsetted(index: Index, by n: IndexDistance, limitedBy limit: Index) -> Index<br class=""></div><div style="line-height: 19.6px;" class=""><br class=""></div><div style="line-height: 19.6px;" class="">func offset(index: inout Index, offsetBy n: IndexDistance)<br class=""></div><div style="line-height: 19.6px;" class="">func offset(index: inout Index, offsetBy n: IndexDistance, limitedBy limit: Index)</div></div><div style="line-height: 19.6px;" class=""><br class=""></div><div style="line-height: 19.6px;" class=""><br class=""></div><br class=""><!-- <signature> --><b class="">Patrick Smith</b><br class=""><!-- </signature> --></div></div><div class="gmail_quote">
On Apr 26 2016, at 11:52 am, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr" class=""><div class=""><div class="">On Mon, Apr 25, 2016 at 8:25 PM, Dave Abrahams <span dir="ltr" class=""><<a href="mailto:dabrahams@apple.com" target="_blank" class="">dabrahams@apple.com</a>></span> wrote:<br class=""><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class=""><span class=""><br class="">
on Mon Apr 25 2016, Xiaodi Wu <<a href="http://xiaodi.wu-at-gmail.com/" rel="noreferrer" target="_blank" class="">xiaodi.wu-AT-gmail.com</a>> wrote:<br class="">
<br class="">
> On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:<br class="">
><br class="">
> on Mon Apr 25 2016, Xiaodi Wu <<a href="http://xiaodi.wu-at-gmail.com/" rel="noreferrer" target="_blank" class="">xiaodi.wu-AT-gmail.com</a>> wrote:<br class="">
><br class="">
> > Quick thought:<br class="">
> ><br class="">
> > Why are you reaching for the "form..." rule for the mutating methods when<br class="">
> there<br class="">
> > are clear verb counterparts?<br class="">
> > location: locate<br class="">
> > successor: succeed<br class="">
><br class="">
> We're not using successor(i) anymore, as noted below, and furthermore<br class="">
> c.succeed(&i) strongly implies the wrong meaning.<br class="">
><br class="">
> I thought that's what I understood from the email, but in the linked proposal<br class="">
> they're still there (as are the many types of Range protocols). Wrong link, or<br class="">
> just not updated?<br class="">
<br class="">
</span>My mistake; I pushed to the wrong repo. Please try again.<br class=""></blockquote><div class=""><br class=""></div><div class="">I see a new version, but I still see .successor().</div><div class=""> </div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class="">
<span class=""><br class="">
> I didn't consider<br class="">
> using<br class="">
><br class="">
> c. locate(...:&i ... )<br class="">
><br class="">
> primarily because I never thought of it and nobody suggested it IIRC,<br class="">
> but I also don't see how it would work in a family with<br class="">
> c.location(after: i) et al. Suggestions?<br class="">
><br class="">
> I didn't read this proposal carefully on its initial presentation for review.<br class="">
> Looking at it now, I wonder about the wisdom of "location"--I understand the<br class="">
> rationale of avoiding multiple methods named "index" that do different things,<br class="">
> but these particular functions return or mutate indices, and nowhere else are<br class="">
> these called "locations". If you're asking for possible alternative suggestions<br class="">
> to avoid using "index", I'll suggest the following here because I don't recall<br class="">
> seeing them offered previously. They read as phrases or sentences:<br class="">
><br class="">
> ```<br class="">
> // taking inspiration from ForwardIndexType, which is no more...<br class="">
> c.advancing(_ i: Index, by offset: IndexDistance, limit: Index)<br class="">
<br class="">
</span>As I've said before, the “ing” suffix strongly implies we're returning<br class="">
(a version of) `c`, not of `i`. c.f.<br class="">
<br class="">
Please hand me **your coat, emptying the left pocket**.<br class="">
<br class="">
You're not going to get a pocket; you're getting a whole coat.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.]</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class="">
<span class=""><br class="">
> c.advance(_ i: inout Index, by offset: IndexDistance, limit: Index)<br class="">
><br class="">
> // or alternatively, using the terminology in the comments that sit above<br class="">
> `location`<br class="">
> c.offsetting(_ i: Index, by n: IndexDistance, limit: Index)<br class="">
> c.offset(_ i: inout Index, by n: IndexDistance, limit: Index)<br class="">
><br class="">
> // and then, in place of successor, etc.<br class="">
> c.incrementing(_ i: Index, limit: Index)<br class="">
> c.increment(_ i: inout Index, limit: Index)<br class="">
> c.decrementing(_ i: Index, limit: Index)<br class="">
> c.decrement(_ i: inout Index, limit: Index)<br class="">
> ```<br class="">
> ("'Limit' doesn't read like a phrase," you might say. Well, think of a coupon:<br class="">
> "$1 off one tub of margarine. Limit one per purchase. Void if transferred or<br class="">
> sold.")<br class="">
<br class="">
</span>the limit label is the least of my concerns here :-)<br class=""></blockquote><div class=""><br class=""></div><div class="">That said, orthogonally, I feel like many `limitedBy` labels can be simplified to `limit` :)</div><div class=""> </div><div class=""><br class=""></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class="">
<div class=""><div class=""><br class="">
> > On Mon, Apr 25, 2016 at 1:24 PM, Dave Abrahams via swift-evolution<br class="">
> > <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
> ><br class="">
> > on Wed Apr 20 2016, Chris Lattner <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
> ><br class="">
> > > On Apr 10, 2016, at 2:41 PM, Chris Lattner<br class="">
> > > <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:<br class="">
> > ><br class="">
> > > Hello Swift community,<br class="">
> > ><br class="">
> > > The review of "A New Model for Collections and Indices" begins now and<br class="">
> > runs<br class="">
> > > through April 18th. The proposal is available here:<br class="">
> > ><br class="">
> > ><br class="">
> ><br class="">
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md</a><br class="">
><br class="">
> ><br class="">
> > ><br class="">
> > > Reviews are an important part of the Swift evolution process. All<br class="">
> reviews<br class="">
> > > should be sent to the swift-evolution mailing list at:<br class="">
> > > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
> > > or, if you would like to keep your feedback private, directly to the<br class="">
> > review<br class="">
> > > manager.<br class="">
> > ><br class="">
> > > A quick update: the core team met to discuss this. They agreed to accept<br class="">
> > it with<br class="">
> > > some naming-related revisions to the proposal (in response to community<br class="">
> > > feedback). Dave is organizing this feedback, and I’ll send out the<br class="">
> formal<br class="">
> > > announcement when that is ready.<br class="">
> ><br class="">
> > The final revisions are reflected in the latest version of the<br class="">
> > proposal:<br class="">
> ><br class="">
> ><br class="">
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md</a><br class="">
><br class="">
> ><br class="">
> > Summary:<br class="">
> ><br class="">
> > * We decided to take Shawn Erickson's excellent suggestion<br class="">
> > <<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/14450" rel="noreferrer" target="_blank" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/14450</a>> to<br class="">
> > use “location” uniformly for index movement, so instead of<br class="">
> > successor(i) and predecessor(i) we have location(after: i) and<br class="">
> > location(before: i).<br class="">
> ><br class="">
> > * Since Brent Royal-Gordon pointed out<br class="">
> ><br class="">
> <<a href="http://news.gmane.org/find-root.php?message_id=156D8FB1%2d1FD3%2d448E%2d8C70%2d6E7400629BC0%40architechies.com" rel="noreferrer" target="_blank" class="">http://news.gmane.org/find-root.php?message_id=156D8FB1%2d1FD3%2d448E%2d8C70%2d6E7400629BC0%40architechies.com</a><br class="">
><br class="">
> > ><br class="">
> > that two of the three proposed Range protocols would likely disappear<br class="">
> > in future updates, we took another look at all of them. Finding<br class="">
> > `RangeProtocol` itself to be a very weak abstraction, we removed all<br class="">
> > three from the proposal.<br class="">
> ><br class="">
> > For those interested in details, implementation work proceeds apace on<br class="">
> > the swift-3-indexing-model branch at<br class="">
> ><br class="">
> <<a href="https://github.com/apple/swift/tree/swift-3-indexing-model/stdlib/public/core" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift/tree/swift-3-indexing-model/stdlib/public/core</a><br class="">
><br class="">
> > >.<br class="">
> ><br class="">
> > P.S. If anyone is interested in contributing, there are still plenty of<br class="">
> > FIXMEs left for us to handle ;-)<br class="">
> ><br class="">
> > --<br class="">
> > Dave<br class="">
> ><br class="">
> > _______________________________________________<br class="">
> > swift-evolution mailing list<br class="">
> > <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
> ><br class="">
><br class="">
> --<br class="">
> Dave<br class="">
><br class="">
<br class="">
</div></div><span class="">--<br class="">
Dave<br class="">
</span></blockquote></div><br class=""></div></div>
</blockquote>
</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>