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

On Mon, May 2, 2016 at 3:08 PM, Karl via swift-evolution wrote: > So, just confirming that the following is going to change: > > — > var string= "test" > let origLen = 4 > let indexOne = string.startIndex > > string.appendContentsOf("ANOTHERTEST") > > let indexTwo = indexOne.advancedBy(

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

> 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

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

+1 — Proposal looks fantastic. It’s very clear and intuitive. Thanks for listening to our feedback! **Patrick Smith** On Apr 27 2016, at 7:50 am, Dave Abrahams via swift-evolution wrote: > on Tue Apr 26 2016, Haravikk wrote: > >

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

Am 27. April 2016 um 01:16 schrieb Dave Abrahams : on Tue Apr 26 2016, Thorsten Seitz wrote: Am 26. April 2016 um 01:16 schrieb Dave Abrahams via swift-evolution : on Mon Apr 25 2016, Xiaodi Wu wrote: Quick thought: Why are you reaching for the "form..." rule for the mutating metho

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

on Tue Apr 26 2016, Haravikk 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:In

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

on Mon Apr 25 2016, Xiaodi Wu wrote: > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams > wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > Quick thought: > > > > Why are you reaching for the "form..." rule for the mutating methods > when > there > > are clear verb c

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

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(_ in

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

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

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

On Mon, Apr 25, 2016 at 8:25 PM, Dave Abrahams wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams > wrote: > > > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > > > Quick thought: > > > > > > Why are you reaching for the "form..."

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

on Mon Apr 25 2016, Xiaodi Wu wrote: > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > Quick thought: > > > > Why are you reaching for the "form..." rule for the mutating methods > when > there > > are clear verb cou

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

On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams wrote: > > on Mon Apr 25 2016, Xiaodi Wu 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

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

on Mon Apr 25 2016, Xiaodi Wu 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)

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

Quick thought: Why are you reaching for the "form..." rule for the mutating methods when there are clear verb counterparts? location: locate successor: succeed On Mon, Apr 25, 2016 at 1:24 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Wed Apr 20 2016, Chris La

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

on Wed Apr 20 2016, Chris Lattner wrote: > On Apr 10, 2016, at 2:41 PM, Chris Lattner > 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://githu

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

On Apr 10, 2016, at 2:41 PM, Chris Lattner 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-co

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

on Tue Apr 19 2016, Thorsten Seitz wrote: > Yup, I just tested on scastie.org, extending my earlier example: > > class Coll(val elements: List[Int]) { > case class Index(val value: Int) > def firstIndex: Index = Index(0) > def get(index: Index) = elements(index.value) > def slice(start: Index) =

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

Yup, I just tested on scastie.org, extending my earlier example: class Coll(val elements: List[Int]) { case class Index(val value: Int) def firstIndex: Index = Index(0) def get(index: Index) = elements(index.value) def slice(start: Index) = new Slice(start.value) class Sli

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

> Am 18.04.2016 um 23:54 schrieb Dave Abrahams via swift-evolution > : > > > on Sat Apr 16 2016, Thorsten Seitz wrote: > >>> Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution >>> : >>> On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote: > On 2016-04-1

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

> On Apr 18, 2016, at 4:52 PM, Dave Abrahams via swift-evolution > wrote: > >> > > Again you're encoding “I'm at the end” in the index, which as we've > agreed does not work. If nothing else, it works—and seems natural—for linked lists. Sorry; if I’d remembered this elementary example soo

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

A Scala like new-Iterator pattern, using path-dependent typing, might be: struct Range { ... } func ..< (lowest: T, highest: T) { ... } struct Array: Collection { static struct Iterator { ... } // Note static ... func next(iterator: inout Iterator) -> Element? { ... } subscript(range: Range)

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

on Sun Apr 17 2016, Thorsten Seitz wrote: > The nonmutating forms successor/predecessor were fine. No need to > match them with the mutating ones IMO. Our API guidelines say that we should match them. We should have a better reason to depart from the API guidelines than “some people don't like

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

on Sat Apr 16 2016, Thorsten Seitz wrote: >> Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution >> : >> >> On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote: >>> On 2016-04-12 Dmitri Gribenko via swift-evolution wrote: > Not even to mention that indices

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

on Thu Apr 14 2016, plx wrote: >> On Apr 14, 2016, at 12:12 PM, Dave Abrahams via swift-evolution >> wrote: No, you can't, at least not usefully. An Index that's at the end of one collection is in the middle of another, or with a suitably-modified version of the same coll

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

> Am 18.04.2016 um 08:16 schrieb Dmitri Gribenko : > >> On Sun, Apr 17, 2016 at 11:14 PM, Thorsten Seitz wrote: >> Preventing indices of one collection being used by another collection can be >> done by using path dependent types like in Scala. >> >> Then 'i' would have type a.Index (where 'a'

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

The nonmutating forms successor/predecessor were fine. No need to match them with the mutating ones IMO. -Thorsten > Am 13.04.2016 um 21:57 schrieb Dave Abrahams via swift-evolution > : > > > on Wed Apr 13 2016, Dave Abrahams wrote: > >>> Reverse is the best opposite we have of advance, s

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

+1 to Tony's arguments and to increment/decrement -Thorsten > Am 13.04.2016 um 17:45 schrieb Tony Parker via swift-evolution > : > > >> On Apr 12, 2016, at 3:43 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> Thanks for your review, Tony! >> >> on Mon Apr 11 2016, Tony Parker w

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

On Sun, Apr 17, 2016 at 11:14 PM, Thorsten Seitz wrote: > Preventing indices of one collection being used by another collection can be > done by using path dependent types like in Scala. > > Then 'i' would have type a.Index (where 'a' is the instance!) and therefore > b[i] would not typecheck as

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

Preventing indices of one collection being used by another collection can be done by using path dependent types like in Scala. Then 'i' would have type a.Index (where 'a' is the instance!) and therefore b[i] would not typecheck as it would require an index of type b.Index -Thorsten > Am 13.04

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

+1 for Scala's path dependent types. On Saturday, 16 April 2016, Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution < > swift-evolution@swift.org >: > > > > On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksd

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

> > * What is your evaluation of the proposal? 1) I think eliminating intervals increases consistency and reduces confusion. 2) I really like the fact that this will make in-place index traversal methods public. It will reduce the amount of boilerplate for developers implementing new col

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

> Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution > : > > On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote: >> On 2016-04-12 Dmitri Gribenko via swift-evolution wrote: >>> >>> Not even to mention that >>> indices are valid only in context of a particular collection i

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

On 2016-04-15 Dmitri Gribenko wrote: On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote: The proposal requires Index values to be Comparable. Does that mean that indices from different collection instances should be comparable i.e. have a strict total order? No, comparing indices from u

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

Review of: https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md * What is your evaluation of the proposal? I think it is a big improvement over the current collections API. However I have a number of reservations, particularly: 1. The motivation of

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

On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote: > On 2016-04-12 Dmitri Gribenko via swift-evolution wrote: >> >> Not even to mention that >> indices are valid only in context of a particular collection instance, >> so in this model you could validate an index against one collection >> an

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

On 2016-04-12 Dmitri Gribenko via swift-evolution wrote: Not even to mention that indices are valid only in context of a particular collection instance, so in this model you could validate an index against one collection and use it with another one. The proposal requires Index values to be Comp

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

> On Apr 14, 2016, at 12:12 PM, Dave Abrahams via swift-evolution > wrote: >>> >>> No, you can't, at least not usefully. An Index that's at the end of one >>> collection is in the middle of another, or with a suitably-modified version >>> of the same collection. >> >> Sure, in certain concr

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

on Wed Apr 13 2016, plx wrote: > On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed Apr 13 2016, plx > wrote: > > Seriously, just because Swift has Optionals and they're useful for > safety in some scenarios (compared with allowing everyt

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

on Wed Apr 13 2016, plx wrote: >> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Apr 13 2016, plx wrote: >> > >>>On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>>on Tue Apr 12 2016, plx >>> wrote: >>

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

on Wed Apr 13 2016, Shawn Erickson wrote: > On Wed, Apr 13, 2016 at 4:45 PM Dave Abrahams via swift-evolution > wrote: > > Updated proposal: > > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > I like the use of `location(...)` instead

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

> On Apr 14, 2016, at 9:00 AM, Vladimir.S via swift-evolution > wrote: > > [offtopic for "A New Model for Collections and Indices"] > > Just wanted to add my 2 cents to this new naming guidelines proposal that > @Dave pointed to: > "Update API Naming Guidelines and Rewrite Set APIs Accordingly

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

[offtopic for "A New Model for Collections and Indices"] Just wanted to add my 2 cents to this new naming guidelines proposal that @Dave pointed to: "Update API Naming Guidelines and Rewrite Set APIs Accordingly" https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-ap

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

On Wed, Apr 13, 2016 at 4:45 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: Updated proposal: > > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md I like the use of `location(...)` instead of `index(...)`. I strongly sugges

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

> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, plx > wrote: > > Seriously, just because Swift has Optionals and they're useful for > safety in some scenarios (compared with allowing everything to be > null

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

> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, plx wrote: > >>On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution >> wrote: >> >>on Tue Apr 12 2016, plx >> wrote: >> >>Aside: `indices` being irregular c

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

on Wed Apr 13 2016, Dave Abrahams wrote: > on Mon Apr 11 2016, Nate Cook wrote: > >> Proposal link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md >> >> On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution >> wrote: >> >>

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

on Wed Apr 13 2016, plx wrote: >> On Apr 13, 2016, at 4:26 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Apr 12 2016, Brent Royal-Gordon wrote: >> > >>> In these cases, it would be better if the `successor(of:)` method was >>> designed in a way that acknowledged and encap

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

> On Apr 13, 2016, at 4:26 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 12 2016, Brent Royal-Gordon wrote: > >> In these cases, it would be better if the `successor(of:)` method was >> designed in a way that acknowledged and encapsulated the bounds check >> that is usually

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

on Mon Apr 11 2016, Nate Cook wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution > wrote: > > Thanks for your comments, Brent! > > on Sun Apr

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

on Wed Apr 13 2016, Tony Parker wrote: >> On Apr 13, 2016, at 12:57 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Apr 13 2016, Dave Abrahams wrote: >> > Reverse is the best opposite we have of advance, so it makes sense to me. >>> >>> Oh, I get it. >>> O

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

on Wed Apr 13 2016, plx wrote: > On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution > wrote: > > on Tue Apr 12 2016, plx > wrote: > > Aside: `indices` being irregular can be a benefit in the context of > auto-complete. > > * What is your eval

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

> On Apr 13, 2016, at 12:57 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, Dave Abrahams wrote: > >>> Reverse is the best opposite we have of advance, so it makes sense to >>> me. >> >> Oh, I get it. >> >>> Or we could use retreat. =) There are other pairs of wor

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

> On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 12 2016, plx > wrote: > >> Aside: `indices` being irregular can be a benefit in the context of >> auto-complete. >> >>* What is your evaluation of the proposal? >

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

on Tue Apr 12 2016, Brent Royal-Gordon wrote: > Yes, I totally agree that `Collection.subscript(_: Index)` should not > be Optional. > > But I think that index-manipulation methods like `successor(of:)` are > a different story. It is normal and expected that, when you alter an > index, you will

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

on Tue Apr 12 2016, Patrick Smith wrote: > +1 to Tony’s naming suggestions, myself preferring move(index:by:), move > (indexForward:), and move(indexBackward:) as it is the most clear and > consistent. Sure, any individual operation in a mutating/nonmutating pair can be better named if you don'

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

on Wed Apr 13 2016, Dave Abrahams wrote: >> Reverse is the best opposite we have of advance, so it makes sense to >> me. > > Oh, I get it. > >> Or we could use retreat. =) There are other pairs of words that work >> as well, like “increment/decrement”. > > Yeah, unfortunately those carry an in

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

on Wed Apr 13 2016, Tony Parker wrote: > On Apr 12, 2016, at 3:43 PM, Dave Abrahams via swift-evolution > wrote: > > Thanks for your review, Tony! > > on Mon Apr 11 2016, Tony Parker wrote: > > On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution >

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

> On Apr 12, 2016, at 3:43 PM, Dave Abrahams via swift-evolution > wrote: > > > Thanks for your review, Tony! > > on Mon Apr 11 2016, Tony Parker > wrote: > >>> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> Hello Swift

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

> On Apr 13, 2016, at 5:34 AM, Haravikk wrote: > > >> On 13 Apr 2016, at 04:46, plx via swift-evolution >> wrote: >> >> Invalidation is hard and I wouldn’t want anything held up to try and find a >> solution first. > > Oh I agree, that was partly my point though; while this proposal may le

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

> On 13 Apr 2016, at 04:46, plx via swift-evolution > wrote: > > Invalidation is hard and I wouldn’t want anything held up to try and find a > solution first. Oh I agree, that was partly my point though; while this proposal may leave us with the "un-Swifty" issue of being unable to explicitl

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

> I want to make a point that avoiding precondition violations by > removing preconditions is not the solution. When you design an API, > it frequently has some constraints on the arguments or on the > execution environment, which, when violated, prevent the API from > performing the operation cor

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

> On Apr 12, 2016, at 10:53 PM, Dmitri Gribenko wrote: > > On Tue, Apr 12, 2016 at 8:46 PM, plx via swift-evolution > wrote: >> >> On Apr 12, 2016, at 6:11 PM, Haravikk wrote: >> >> I’m a +1 for the proposal (but as I’ve implemented a bunch of collections >> recently I’m not sure I’m looking

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

On Tue, Apr 12, 2016 at 8:46 PM, plx via swift-evolution wrote: > > On Apr 12, 2016, at 6:11 PM, Haravikk wrote: > > I’m a +1 for the proposal (but as I’ve implemented a bunch of collections > recently I’m not sure I’m looking forward to having to update my code to > reflect the new pattern ;) >

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

> On Apr 12, 2016, at 6:11 PM, Haravikk wrote: > > I’m a +1 for the proposal (but as I’ve implemented a bunch of collections > recently I’m not sure I’m looking forward to having to update my code to > reflect the new pattern ;) > > But I’m interested by these concerns: > >> On 12 Apr 2016,

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

+1 to Tony’s naming suggestions, myself preferring move(index:by:), move(indexForward:), and move(indexBackward:) as it is the most clear and consistent. As an aside, I am not a fan of the form- prefix, as it feels generic without being self explanatory. I think another word would work better. I w

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

On Tue, Apr 12, 2016 at 4:27 AM, Brent Royal-Gordon wrote: >>> (On the other hand, it might be that I'm conceiving of the purpose of >>> `limitedBy` differently from you—I think of it as a safety measure, but you >>> may be thinking of it specifically as an automatic truncation mechanism.) >> >>

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

on Tue Apr 12 2016, Brent Royal-Gordon wrote: >>> Huh, that clarifies something. How about the non-`ing` variants? >>> >>> collection.travel(5, from: i) >>> collection.stride(5, from: i) >>> collection.advance(i, by: 5) >> >> Active verb phrases are reserved for methods with side-e

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

I’m a +1 for the proposal (but as I’ve implemented a bunch of collections recently I’m not sure I’m looking forward to having to update my code to reflect the new pattern ;) But I’m interested by these concerns: > On 12 Apr 2016, at 17:57, plx via swift-evolution > wrote: > > # 1: Relatively

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

>> Huh, that clarifies something. How about the non-`ing` variants? >> >> collection.travel(5, from: i) >> collection.stride(5, from: i) >> collection.advance(i, by: 5) > > Active verb phrases are reserved for methods with side-effects according > to the API guidelines. Is there *

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

Thanks for your review, Tony! on Mon Apr 11 2016, Tony Parker wrote: >> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution >> wrote: >> >> Hello Swift community, >> >> The review of "A New Model for Collections and Indices" begins now and runs >> through April 18th. The proposa

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

on Tue Apr 12 2016, plx wrote: > Aside: `indices` being irregular can be a benefit in the context of > auto-complete. > > * What is your evaluation of the proposal? > > +1, very much. > > As a change from the current model, it’s an across-the-board improvement for > me, > at least. > > In a

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

on Tue Apr 12 2016, Nate Cook wrote: > On Apr 12, 2016, at 4:15 AM, Dmitri Gribenko via swift-evolution > wrote: > > On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via > swift-evolution wrote: > > (On the other hand, it might be that I'm conceiving of the purpose of >

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

on Mon Apr 11 2016, Brent Royal-Gordon wrote: >>> If these types are for implementation sharing, should they be >>> underscored to discourage their use? Or is the position they occupy in >>> the type hierarchy important because Range and ClosedRange will >>> eventually occupy them? >> >> Unders

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

on Mon Apr 11 2016, Nate Cook wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution > wrote: > > Thanks for your comments, Brent! > > on Sun Apr

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

Aside: `indices` being irregular can be a benefit in the context of auto-complete. > * What is your evaluation of the proposal? +1, very much. As a change from the current model, it’s an across-the-board improvement for me, at least. In a bigger-picture sense I think Swift would be bett

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

> On Apr 12, 2016, at 4:15 AM, Dmitri Gribenko via swift-evolution > wrote: > > On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via > swift-evolution wrote: >> (On the other hand, it might be that I'm conceiving of the purpose of >> `limitedBy` differently from you—I think of it as a safet

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

>> (On the other hand, it might be that I'm conceiving of the purpose of >> `limitedBy` differently from you—I think of it as a safety measure, but you >> may be thinking of it specifically as an automatic truncation mechanism.) > > Hi Brent, > > Could you explain what kind of safety do you hav

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

On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via swift-evolution wrote: > (On the other hand, it might be that I'm conceiving of the purpose of > `limitedBy` differently from you—I think of it as a safety measure, but you > may be thinking of it specifically as an automatic truncation mec

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

On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via swift-evolution wrote: > So, imagine that we have a type like this in the standard library: > > /// Represents a pre-validated index. A pre-validated index received > from a given collection is > /// guaranteed to refer to a

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

>> If these types are for implementation sharing, should they be >> underscored to discourage their use? Or is the position they occupy in >> the type hierarchy important because Range and ClosedRange will >> eventually occupy them? > > Underscoring hides names from users completely, and IMO that

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

> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution > 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/blo

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

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution > wrote: > > Thanks for your comments, Brent! > > on Sun Apr 10 2016, Brent Royal-Gordon

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

> On Apr 11, 2016, at 1:02 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Apr 11 2016, Stephen Canon wrote: > >> Joe’s isn’t saying that “Indexes” is more common, rather that it’s regular >> (i.e. >> follows the usual declension rule for plurals); there’s tradeoffs each way, >

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

on Mon Apr 11 2016, Dave Abrahams wrote: > Thanks for your comments, Brent! > > on Sun Apr 10 2016, Brent Royal-Gordon wrote: > >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md >> >> Some questions and comments: >> >>> • Tw

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

On Mon, Apr 11, 2016 at 1:01 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > > Compared to this: > > > > collection.index(5, stepsFrom: i) > > > > I would prefer any of these (ordered from least favorite to most): > > > > collection.index(distance: 5, from:

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

I won’t do a full review because I don’t think I have spent enough time reading through the discussion, but just reading the proposal I’d say I’m an huge proponent of this change. Irrespective of the performance benefits, I think it’s a massive win for an easily understandable mental model. Tyl

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

on Mon Apr 11 2016, Joe Groff wrote: >> • Because Swift is unable to express conditional protocol > conformances, implementing this change has required us to create a > great deal of complexity in the standard library API. Aside from the > two excess “Countable” range types, there are new overlo

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

on Mon Apr 11 2016, Stephen Canon wrote: > Joe’s isn’t saying that “Indexes” is more common, rather that it’s regular > (i.e. > follows the usual declension rule for plurals); there’s tradeoffs each way, > but > using the regular plural might make it more familiar for some non-native > speaker

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

Thanks for your comments, Brent! on Sun Apr 10 2016, Brent Royal-Gordon wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > Some questions and comments: > >> • Two for ranges that additionally conform to >> RandomA

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

on Sun Apr 10 2016, Jacob Bandes-Storch wrote: > Minor questions after initial read-through: > > - Should the comment on {index,formIndex}(_:stepsFrom:) say what happens if > the > resulting index would be out of bounds? I don't think we should ever specify what happens when preconditions are

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

> • Because Swift is unable to express conditional protocol conformances, > implementing this change has required us to create a great deal of complexity > in the standard library API. Aside from the two excess “Countable” range > types, there are new overloads for slicing and twelve disti

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

At least in my experience, "indices" is used throughout technical documentation and code, such as the official docs of Python, Java, and C#. I'm not strongly opposed to "indexes", but I think there should be a stronger reason to change it other than that it has easier discoverability for non-Engli

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

Joe’s isn’t saying that “Indexes” is more common, rather that it’s regular (i.e. follows the usual declension rule for plurals); there’s tradeoffs each way, but using the regular plural might make it more familiar for some non-native speakers/readers. – Steve > On Apr 11, 2016, at 9:42 AM, Tre

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

> On Apr 11, 2016, at 9:48 AM, Stephen Canon wrote: > > Joe’s isn’t saying that “Indexes” is more common, rather that it’s regular > (i.e. follows the usual declension rule for plurals); there’s tradeoffs each > way, but using the regular plural might make it more familiar for some > non-nati

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

Thank you Dmitri! > Le 11 avr. 2016 à 18:22, Dmitri Gribenko a écrit : > >> On Mon, Apr 11, 2016 at 9:20 AM, Dmitri Gribenko wrote: >> Hi, >> >>> On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué >>> wrote: >>> Will it still be possible with the new protocol and types? Especially, how >>> to I

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

I disagree. According to both http://grammarist.com/usage/indexes-indices/ and http://www.worldwidewords.org/qa/qa-ind2.htm, "indices" is more common in the English-speaking world (outside of parts of America and Canada) as well as in technical contexts. On Mon, Apr 11, 2016 at 12:29 PM, Joe Groff

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

I love irregular plurals as much as the next grammar nerd, but I think it'd be better to use the more regular, but still correct, plural "indexes" rather than "indices". -Joe > On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review

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

On Mon, Apr 11, 2016 at 9:20 AM, Dmitri Gribenko wrote: > Hi, > > On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué > wrote: >> Will it still be possible with the new protocol and types? Especially, how >> to I generate "BETWEEN 0 AND 17" from 0..<18 without a supporting collection >> that gives m

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

Hi, On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué wrote: > Will it still be possible with the new protocol and types? Especially, how to > I generate "BETWEEN 0 AND 17" from 0..<18 without a supporting collection > that gives me the predecessor of 18? You would either design your API to accept

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

Hello, I have a user question regarding the proposed range types that replace the old range/interval. The old hierachy allowed me to turn ranges to SQL expressions through the following mapping (see https://github.com/groue/GRDB.swift/blob/v0.57.0/GRDB/FetchRequest/SQLOperator.swift#L335-L365)

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

> * What is your evaluation of the proposal? +1. I think it makes the collection model more simple and more flexible at the same time. By coupling index to a specific collection, rather then treating it as a separate, independent entity, we can more easily implement alternative collection

  1   2   >