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.
> 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]
> <mailto:[email protected]>> wrote:
>
> on Mon Apr 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com
> <http://xiaodi.wu-at-gmail.com/>> wrote:
>
> > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > on Mon Apr 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com
> > <http://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] <mailto:[email protected]>> wrote:
> > >
> > > on Wed Apr 20 2016, Chris Lattner <[email protected]
> > <mailto:[email protected]>> wrote:
> > >
> > > > On Apr 10, 2016, at 2:41 PM, Chris Lattner
> > > > <[email protected] <mailto:[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
> >
> > <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
> > <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
> >
> > <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
> > <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
> >
> > <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
> >
> > <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] <mailto:[email protected]>
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > <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
