[swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Dave Abrahams dabrahams at apple.com
Tue Apr 26 16:46:33 CDT 2016


on Tue Apr 26 2016, Haravikk <swift-evolution at swift.org> wrote:

> 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.

I agree and have updated the proposal accordingly.

https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md

>
>     On 26 Apr 2016, at 08:49, Patrick Smith via swift-evolution
>     <swift-evolution at swift.org> 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
>     <swift-evolution at swift.org> wrote: 
>
>         On Mon, Apr 25, 2016 at 8:25 PM, Dave Abrahams <dabrahams at apple.com>
>         wrote:
>
>             on Mon Apr 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>
>             > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams
>             <dabrahams at apple.com> wrote:
>             >
>             > on Mon Apr 25 2016, Xiaodi Wu <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
>             > > <swift-evolution at swift.org> wrote:
>             > >
>             > > on Wed Apr 20 2016, Chris Lattner
>             <swift-evolution at swift.org> wrote:
>             > >
>             > > > On Apr 10, 2016, at 2:41 PM, Chris Lattner
>             > > > <clattner at apple.com> 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
>
>             >
>             > >
>             > > >
>             > > > 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
>             > > > 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
>
>             >
>             > >
>             > > Summary:
>             > >
>             > > * We decided to take Shawn Erickson's excellent suggestion
>             > > <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
>
>             >
>             > > >
>             > > 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
>
>             >
>             > > >.
>             > >
>             > > P.S. If anyone is interested in contributing, there are still
>             plenty of
>             > > FIXMEs left for us to handle ;-)
>             > >
>             > > --
>             > > Dave
>             > >
>             > > _______________________________________________
>             > > swift-evolution mailing list
>             > > swift-evolution at swift.org
>             > > https://lists.swift.org/mailman/listinfo/swift-evolution
>             > >
>             >
>             > --
>             > Dave
>             >
>
>             --
>             Dave
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Thanks!

-- 
Dave



More information about the swift-evolution mailing list