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

Mon Apr 25 20:25:10 CDT 2016

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

> 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 :-)

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