Re: [swift-evolution] Feature proposal: Range operator with step

Thorsten Seitz via swift-evolution writes: > > > Am 03.05.2016 um 13:42 schrieb Hans Huck via swift-evolution swift.org>: > > > > Thorsten Seitz via swift-evolution ...> writes: > >> > >> -1 > >> > >> I don't see the need for special syntax where a method can be easily used > > and is more g

Re: [swift-evolution] Feature proposal: Range operator with step

> Am 03.05.2016 um 13:42 schrieb Hans Huck via swift-evolution > : > > Thorsten Seitz via swift-evolution writes: >> >> -1 >> >> I don't see the need for special syntax where a method can be easily used > and is more general. >> >> -Thorsten >> > > That, dear Thorsten, is a non-argument.

Re: [swift-evolution] Feature proposal: Range operator with step

Thorsten Seitz via swift-evolution writes: > > -1 > > I don't see the need for special syntax where a method can be easily used and is more general. > > -Thorsten > That, dear Thorsten, is a non-argument. Why? Let's see, how about "I don't see the need for a For-loop where a While-loop can be

Re: [swift-evolution] Feature proposal: Range operator with step

-1 I don't see the need for special syntax where a method can be easily used and is more general. -Thorsten > Am 18.04.2016 um 17:28 schrieb Vladimir.S via swift-evolution > : > > On 15.04.2016 3:57, Hans Huck via swift-evolution wrote: > > Anyway, why not just make it .step() then, like in

Re: [swift-evolution] Feature proposal: Range operator with step

On 15.04.2016 3:57, Hans Huck via swift-evolution wrote: > Anyway, why not just make it .step() then, like in Ruby? > > Instead of a "by" keyword, I'd be happy with syntactic sugar in the form of > > for i in p1..As for 'step' word: It seems like for now IMO this is the best suggestion : very exp

Re: [swift-evolution] Feature proposal: Range operator with step

Brent Royal-Gordon via swift-evolution writes: > > > for i in p1.. > > > as syntactic sugar for and internally mapped to > > > > for i in (p1.. > > > Best of both worlds? > > Look. It is very, very unlikely that you will get people to add syntactic > sugar *just* for striding and *just* for t

Re: [swift-evolution] Feature proposal: Range operator with step

“|” often means “with” in math, which is only one word off from “with step”. func | (range: Range, stride: T.Stride) -> IntegerStrideTo { return IntegerStrideTo(_start: range.startIndex, end: range.endIndex, stride: stride) } var arr = [Int]() for i in (0 ..< 10) | 2 { arr.append(i) } ar

Re: [swift-evolution] Feature proposal: Range operator with step

> for i in p1.. > as syntactic sugar for and internally mapped to > > for i in (p1.. > Best of both worlds? Look. It is very, very unlikely that you will get people to add syntactic sugar *just* for striding and *just* for the for loop. If this: for i in (1..<10).striding(by: 2) { … }

Re: [swift-evolution] Feature proposal: Range operator with step

What about "strideby" Brandon > On Apr 14, 2016, at 8:57 PM, Hans Huck via swift-evolution > wrote: > > Erica Sadun via swift-evolution writes: >> >> >>> On Apr 14, 2016, at 1:42 PM, Hans Huck via swift-evolution > swift.org> wrote: >>> Please elaborate. How could >>> >>> for i in (1...1

Re: [swift-evolution] Feature proposal: Range operator with step

Erica Sadun via swift-evolution writes: > > > > On Apr 14, 2016, at 1:42 PM, Hans Huck via swift-evolution swift.org> wrote: > > Please elaborate. How could > > > > for i in (1...10).by(3) > > > > possibly be misinterpreted? > > > > (1..<11), (4..<14), (7..<17)... > Or (3..<30)? :) With

Re: [swift-evolution] Feature proposal: Range operator with step

Dave Abrahams via swift-evolution writes: > > > on Thu Apr 14 2016, Hans Huck swift.org> wrote: > > > Dave Abrahams via swift-evolution ...> writes: > > > >> > >> If I thought extreme concision was important for this application, I'd be > >> proposing something like > >> > >> for x in 0.

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 14, 2016, at 1:42 PM, Hans Huck via swift-evolution > wrote: > Please elaborate. How could > > for i in (1...10).by(3) > > possibly be misinterpreted? > (1..<11), (4..<14), (7..<17)... -- E ___ swift-evolution mailing list swift-evoluti

Re: [swift-evolution] Feature proposal: Range operator with step

on Thu Apr 14 2016, Hans Huck wrote: > Dave Abrahams via swift-evolution writes: > >> >> If I thought extreme concision was important for this application, I'd be >> proposing something like >> >> for x in 0.0..<20.0//1.3 {} >> >> but personally, I don't, >> > And that is why exactly? The

Re: [swift-evolution] Feature proposal: Range operator with step

Dave Abrahams via swift-evolution writes: > > If I thought extreme concision was important for this application, I'd be > proposing something like > > for x in 0.0..<20.0//1.3 {} > > but personally, I don't, > And that is why exactly? The For-loop is at the very core of the language and one

Re: [swift-evolution] Feature proposal: Range operator with step

on Fri Apr 08 2016, Erica Sadun wrote: >> On Apr 6, 2016, at 3:32 PM, Dave Abrahams wrote: >> >> >> on Wed Apr 06 2016, Erica Sadun wrote: >> > >>>On Apr 6, 2016, at 3:25 PM, Dave Abrahams wrote: >>> >>>These all look reasonable to me. >>> >>>Lastly, if you want the posit

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 3:32 PM, Dave Abrahams wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>On Apr 6, 2016, at 3:25 PM, Dave Abrahams wrote: >> >>These all look reasonable to me. >> >>Lastly, if you want the positive stride reversed, you'd do just that: >> >>

Re: [swift-evolution] Feature proposal: Range operator with step

> At the risk of asking one of those newbie questions, why bother with StrideTo > and StrideThrough? Isn't a Generator or Array more to the point? You don't want to return an Array because you want to generate the values lazily. If `stride(over: 1..<1_000_000, by: 10)` returned an Array, you wou

Re: [swift-evolution] Feature proposal: Range operator with step

> On Mar 30, 2016, at 12:26 AM, Xiaodi Wu via swift-evolution > wrote: > > I didn't seem to ever need division. See attached playground (which > borrows shamelessly from existing code and Erica's proposal, and which > is written in Swift 2.2 because that's what I had handy). Appending the follo

Re: [swift-evolution] Feature proposal: Range operator with step

At the risk of asking one of those newbie questions, why bother with StrideTo and StrideThrough? Isn't a Generator or Array more to the point? > On Apr 7, 2016, at 5:59 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I'm confused. There is an instance owning the start and end. It's cal

Re: [swift-evolution] Feature proposal: Range operator with step

Conceptually, maybe? But of course the sequence is lazily evaluated, so the only state stored in an instance of StrideTo is one value for the current iteration; all the other properties in a StrideTo are just the inputs to the stride function, and no length is computed let alone stored. I get that

Re: [swift-evolution] Feature proposal: Range operator with step

> I'm confused. There is an instance owning the start and end. It's called > StrideTo or StrideThrough, conforms to Sequence (with a FIXME comment that it > should conform to Collection) and is distinct from Range and from the > Strideable bounds themselves. Is that different from what you're de

Re: [swift-evolution] Feature proposal: Range operator with step

I'm confused. There is an instance owning the start and end. It's called StrideTo or StrideThrough, conforms to Sequence (with a FIXME comment that it should conform to Collection) and is distinct from Range and from the Strideable bounds themselves. Is that different from what you're describing?

Re: [swift-evolution] Feature proposal: Range operator with step

>> Actually, it would need to be something like >> `calendar[startDate..> NSCalendarUnit is not itself a stride, it is the *unit* of the >> stride. > > Maybe: > > calendar.days[startDate.. However, it doesn't explain why > > calendar[startDate.. > “doesn't quite help.” It seems to me that

Re: [swift-evolution] Feature proposal: Range operator with step

Hi All. nearly no one has yet reacted on my mail, echoed here again, which leaves by me the following questions pending: -does what I define and describe completely cover all the required functionality for ranges for all numerical types? -does it eliminate the need for using “Stride(...)” at

Re: [swift-evolution] Feature proposal: Range operator with step

on Thu Apr 07 2016, Brent Royal-Gordon wrote: >>> calendar.using(.Day).stride(from: startDate, to: endDate, by: 1) >> >>> The `start` and `end` parameters could be grouped together into a >>> single parameter to match `stride(over:by:)`, but you can't put the >>> calendar or the unit into the s

Re: [swift-evolution] Feature proposal: Range operator with step

>> calendar.using(.Day).stride(from: startDate, to: endDate, by: 1) > >> The `start` and `end` parameters could be grouped together into a >> single parameter to match `stride(over:by:)`, but you can't put the >> calendar or the unit into the stride—without them, there is no >> coherent way t

Re: [swift-evolution] Feature proposal: Range operator with step

Dijkstra is talking about intervals of natural numbers, i.e. indices. Range is much more general than that, including floating point ranges, so Dijkstra's arguments do not apply here. -Thorsten Am 06.04.2016 um 23:41 schrieb Brent Royal-Gordon via swift-evolution : >> From a purely numericall

Re: [swift-evolution] Feature proposal: Range operator with step

> Am 06.04.2016 um 23:26 schrieb Stephen Canon via swift-evolution > : > > >> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >>> on Wed Apr 06 2016, Erica Sadun wrote: >>> >>> On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution >>>wrote: >>>

Re: [swift-evolution] Feature proposal: Range operator with step

> Am 06.04.2016 um 23:03 schrieb Dave Abrahams via swift-evolution > : > > >> on Wed Apr 06 2016, Erica Sadun wrote: >> >>On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >>Guidance: >> >>When using odd integer literals to produce an even numbe

Re: [swift-evolution] Feature proposal: Range operator with step

> Am 06.04.2016 um 22:17 schrieb Xiaodi Wu via swift-evolution > : > >> On Wed, Apr 6, 2016 at 1:43 PM, Dave Abrahams wrote: >> >>> on Wed Apr 06 2016, Erica Sadun wrote: >>> >>>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution >>> wrote: >>>(0..<199).striding(by: -

Re: [swift-evolution] Feature proposal: Range operator with step

> Am 06.04.2016 um 20:26 schrieb Erica Sadun via swift-evolution > : > >>> On Apr 6, 2016, at 12:23 PM, Stephen Canon via swift-evolution >>> wrote: >>> >>> On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution wrote: On Apr 6, 2016, at 11:16 AM, Dave Abrahams

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 17:00, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu wrote: >>> Prohibiting StrideTo with floating-point ranges altogether would be >>> distressing. IMO, it's plenty distressing that

Re: [swift-evolution] Feature proposal: Range operator with step

I like the idea that Array gains `strinding(by:)` but would also like Range to be like an array, same interface, and hence also gain `strinding(by:)`, hence: calendar[(startDate ..< endDate).striding(by: .Day)] -- Howard. On 7 April 2016 at 10:53, Dave Abrahams via swift-evolution < swift-evo

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Brent Royal-Gordon wrote: >> I (am familiar with and) agree with Dijkstra's logic, but not with your >> conclusion about it. The fact that one representation is more natural >> for most common computing tasks doesn't mean it's not worth supporting >> the other representation

Re: [swift-evolution] Feature proposal: Range operator with step

> I (am familiar with and) agree with Dijkstra's logic, but not with your > conclusion about it. The fact that one representation is more natural > for most common computing tasks doesn't mean it's not worth supporting > the other representations. I'm not saying that Dijkstra proves that we don't

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Howard Lovatt wrote: > Dijkstra specifically said that in Mesa it was a bad idea to include anything > other than `..<` the relevent quote is: > > "Extensive experience with Mesa has shown that the use of the other three > conventions has been a constant source of clumsiness

Re: [swift-evolution] Feature proposal: Range operator with step

Dijkstra specifically said that in Mesa it was a bad idea to include anything other than `..<` the relevent quote is: "Extensive experience with Mesa has shown that the use of the other three conventions has been a constant source of clumsiness and mistakes, and on account of that experience Mesa

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Brent Royal-Gordon wrote: >> From a purely numerically aesthetic point of view, I'd much prefer ranges to >> be >> openable and closable at both ends. >> >> My primary use-case has been teaching math using playgrounds but I'm sure >> there are lots of other real-world si

Re: [swift-evolution] Feature proposal: Range operator with step

Hi Milos Yes, (v1…v2).by(v3) it can determine the going of either in + or - direction, but only at run time! because the contents of v1, v2, v3 are of course unknown at compile time. Ergo: it cannot expected be an absolute value. however, I suggested (coded) that here on 4.3.2016… Works in

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Erica Sadun wrote: > On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed Apr 06 2016, Xiaodi Wu wrote: > > On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution > wrote: > > You if you need to re

Re: [swift-evolution] Feature proposal: Range operator with step

> From a purely numerically aesthetic point of view, I'd much prefer ranges to > be > openable and closable at both ends. > > My primary use-case has been teaching math using playgrounds but I'm sure > there are lots of other real-world situations more specific to common > numerical > method

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Erica Sadun wrote: > On Apr 6, 2016, at 3:25 PM, Dave Abrahams wrote: > > These all look reasonable to me. > > Lastly, if you want the positive stride reversed, you'd do just that: > > (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0] > > Als

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 3:25 PM, Dave Abrahams wrote: > > These all look reasonable to me. > >>Lastly, if you want the positive stride reversed, you'd do just that: >> >>(0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0] > > Also reasonable. > > -- > Dave Unless there's a compelli

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution >> wrote: >> >>on Wed Apr 06 2016, Xiaodi Wu wrote: >> >>On Wed, Apr 6, 2016 at 3:28

Re: [swift-evolution] Feature proposal: Range operator with step

Hi Ted, > that would imply the ‘by”value should/must always be an absolute value? In a way: Instead of `Strideable.Stride` I would suggest `Strideable.Distance`. At any rate, leaving the sign to be direction indicator makes it forever necessary for everyone to make this counterintuitive metal

Re: [swift-evolution] Feature proposal: Range operator with step

On Wed, Apr 6, 2016 at 4:05 PM, Dave Abrahams wrote: > > on Wed Apr 06 2016, Xiaodi Wu wrote: > >> On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution >> wrote: >>> You if you need to represent `<..` intervals in scientific computing, >>> that's a pretty compelling argument for sup

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Erica Sadun wrote: > On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution > wrote: > > Guidance: > > When using odd integer literals to produce an even number sequence, > prefer the `...` operator to the `..<` operator and change your end

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Xiaodi Wu > wrote: > >> On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution >> wrote: >>> You if you need to represent `<..` intervals in scientif

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Xiaodi Wu wrote: > On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution > wrote: >> You if you need to represent `<..` intervals in scientific computing, >> that's a pretty compelling argument for supporting them. >> >>> I'd like to be able to represent any of t

Re: [swift-evolution] Feature proposal: Range operator with step

On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution wrote: > You if you need to represent `<..` intervals in scientific computing, > that's a pretty compelling argument for supporting them. > >> I'd like to be able to represent any of those as >> Intervals-which-are-now-Ranges. It ma

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Erica Sadun wrote: >> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu wrote: >> Prohibiting StrideTo with floating-point ranges altogether would be >> distressing. IMO, it's plenty distressing that backwards >> floating-point StrideTo as it currently exists might go away. > > I wouldn

Re: [swift-evolution] Feature proposal: Range operator with step

G Typos… Sorry, here it is again: vital correctionslook at<< < Hi Erica, Dave Based on what I’ve (not all) read under this topic: I’d suggest a more complete approach: Ranges should support: (as yet not implemented) - All numerical data types (Double, Float, Int, Money

Re: [swift-evolution] Feature proposal: Range operator with step

On Wed, Apr 6, 2016 at 1:29 PM Pyry Jahkola via swift-evolution < swift-evolution@swift.org> wrote: > > On 06 Apr 2016, at 23:17, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > I don't think you can fix counterintuitive behavior with guidance. > > (1..<199).striding(by

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 2:35 PM, Erica Sadun via swift-evolution > wrote: > > Yes, but you can with warnings and fixits. > > * The compiler should issue a warning for any use of > > (n.. > with a fixit of "replace (n.. whether n or m is known at compile time > > * If v cannot be known at c

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 2:28 PM, Dave Abrahams via swift-evolution > wrote: > You if you need to represent `<..` intervals in scientific computing, > that's a pretty compelling argument for supporting them. >From a purely numerically aesthetic point of view, I'd much prefer ranges to >be openabl

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution > wrote: >> Guidance: >> >> When using odd integer literals to produce an even number sequence, >> prefer the `...` operator to the `..<` operator and change your ending >> literal to an even number. > > I don't think you can fix

Re: [swift-evolution] Feature proposal: Range operator with step

Hello Milos, Good question was thinking about this too. that would imply the ‘by”value should/must always be an absolute value? however (if it is a var) it cannot be guaranteed to be + or - that’s why I thought to leave it as is. ? TedvG > On 06.04.2016, at 22:18, Milos Rankovic wrote: > > >>

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Xiaodi Wu wrote: > On Wed, Apr 6, 2016 at 1:16 PM, Dave Abrahams wrote: >> >> on Wed Apr 06 2016, Xiaodi Wu wrote: >> >>> I think a lightbulb just went on for me: >>> > >>> You're talking about expressing something in the vein of >>> `(0..<200).striding(by: >>> -2)`, which

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu wrote: > Prohibiting StrideTo with floating-point ranges altogether would be > distressing. IMO, it's plenty distressing that backwards > floating-point StrideTo as it currently exists might go away. I wouldn't suggest doing so. I'm just saying that for a

Re: [swift-evolution] Feature proposal: Range operator with step

> On 06 Apr 2016, at 23:17, Dave Abrahams via swift-evolution > wrote: > > I don't think you can fix counterintuitive behavior with guidance. > > (1..<199).striding(by: -2) is the first way I'd reach for to express > 197, 195, ..., 3, 1 I think a sensible specification would be that with a

Re: [swift-evolution] Feature proposal: Range operator with step

Apologies, I inverted the operator there! This is, of course what I meant: > On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution > wrote: > > v1 > v2: is allowed and correctly evaluated. e.g. > (8.0…-3.14159).by(-0.0001) If the range does not assume `start <= end`, is it sti

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Erica Sadun wrote: >> On Apr 6, 2016, at 12:43 PM, Dave Abrahams wrote: >> >> >> on Wed Apr 06 2016, Erica Sadun wrote: >> > >>>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution >>> wrote: >>>(0..<199).striding(by: -2) >>> >>>are even or odd

Re: [swift-evolution] Feature proposal: Range operator with step

> On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution > wrote: > > v1 > v2: is allowed and correctly evaluated. e.g. > (8.0…-3.14159).by(-0.0001) If the range does not assume `start >= end`, is it still necessary to also indicate the traversal direction with the sign of the

Re: [swift-evolution] Feature proposal: Range operator with step

On Wed, Apr 6, 2016 at 1:43 PM, Dave Abrahams wrote: > > on Wed Apr 06 2016, Erica Sadun wrote: > >> On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution >> wrote: >> (0..<199).striding(by: -2) >> >> are even or odd. >> >> (0..<199).striding(by: -2): 0..<199 == 0...198

Re: [swift-evolution] Feature proposal: Range operator with step

On Wed, Apr 6, 2016 at 1:16 PM, Dave Abrahams wrote: > > on Wed Apr 06 2016, Xiaodi Wu wrote: > >> I think a lightbulb just went on for me: >> >> You're talking about expressing something in the vein of >> `(0..<200).striding(by: >> -2)`, which has I'm sure many use cases, and which isn't straig

Re: [swift-evolution] Feature proposal: Range operator with step

Hi Erica, Dave Based on what I’ve (not all) read under this topic: I’d suggest a more complete approach: Ranges should support: (as yet not implemented) - All numerical data types (Double, Float, Int, Money***, Decimal*** ) - An arbitrary increment or decrement value. - Working in the compl

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 12:43 PM, Dave Abrahams wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution >> wrote: >>(0..<199).striding(by: -2) >> >>are even or odd. >> >> (0..<199).striding(by: -2): 0..<199 == 0...1

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Erica Sadun wrote: > On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution > wrote: > (0..<199).striding(by: -2) > > are even or odd. > > (0..<199).striding(by: -2): 0..<199 == 0...198 Even > (1..<199).striding(by: -2): 1..<199 == 1...198 Even I und

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 12:30 PM, Dave Abrahams via swift-evolution > wrote: > on Wed Apr 06 2016, Stephen Canon wrote: >> For the (0..<199) case, Erica’s assessment > > which is...? https://gist.github.com/erica/786ab9703f699db1301be65510e7da03

Re: [swift-evolution] Feature proposal: Range operator with step

> On 6 Apr 2016, at 19:16, Dave Abrahams via swift-evolution > wrote: > > We prefer methods to free functions. However, `(from:to:by)` need not be a free function, it could be a sequence initialiser: Walk(from: 200, to: 0, by: 2) or: Steps(from: 200, to: 0, by: 2) or something alo

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Stephen Canon wrote: > On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution > wrote: > > On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution > wrote: > > One question that I *do* think we should answer, is whether the >

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Milos Rankovic wrote: > On 6 Apr 2016, at 18:57, Xiaodi Wu via swift-evolution > wrote: > > Meanwhile, I was trying to talk about something like `stride(from: 200, > to: > 0, by: -2)`, which is easily expressed today but isn't straightforward at > all to

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 11:26 AM, Erica Sadun wrote: > >> >> On Apr 6, 2016, at 12:23 PM, Stephen Canon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 12:23 PM, Stephen Canon via swift-evolution > wrote: > > >> On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution >>> mailto:swift-evolution@swift

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution > wrote: > >> On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> One question that I *do* think we should answer, is whether the elements >> of >> >>(0..<199).s

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution > wrote: >(0..<199).striding(by: -2) > > are even or odd. (0..<199).striding(by: -2): 0..<199 == 0...198 Even (1..<199).striding(by: -2): 1..<199 == 1...198 Even (0..<198).striding(by: -2): 1..<198 == 0...197 Odd (1..<198).st

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution > wrote: > > One question that I *do* think we should answer, is whether the elements > of > >(0..<199).striding(by: -2) > > are even or odd. Odd. I don’t believe that many real use cases care, but odd is more efficient fr

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Xiaodi Wu wrote: > I think a lightbulb just went on for me: > > You're talking about expressing something in the vein of > `(0..<200).striding(by: > -2)`, which has I'm sure many use cases, and which isn't straightforward to > express with the current free function--I hadn't

Re: [swift-evolution] Feature proposal: Range operator with step

> On 6 Apr 2016, at 18:57, Xiaodi Wu via swift-evolution > wrote: > > Meanwhile, I was trying to talk about something like `stride(from: 200, to: > 0, by: -2)`, which is easily expressed today but isn't straightforward at all > to preserve with only ranges. Precisely because the free functio

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 10:10 AM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Brent Royal-Gordon wrote: > >>> For example, there are all kinds of other ways to slice this: >>> >>> stride(over: 0..<200, by: -2) >> >> This seems like a particularly good solution. The

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 11:10 AM, Dave Abrahams wrote: > Again, I wasn't trying to suggest any of the solutions listed there. > The point I was making was that we don't have enough information to > design more than > >(0..<200).striding(by: -2) I like this a lot but I assure you there will be

Re: [swift-evolution] Feature proposal: Range operator with step

I think a lightbulb just went on for me: You're talking about expressing something in the vein of `(0..<200).striding(by: -2)`, which has I'm sure many use cases, and which isn't straightforward to express with the current free function--I hadn't considered that. Meanwhile, I was trying to talk a

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Apr 06 2016, Brent Royal-Gordon wrote: >> For example, there are all kinds of other ways to slice this: >> >>stride(over: 0..<200, by: -2) > > This seems like a particularly good solution. The way I understand it > at least, it would allow ranges to always be ordered, with the only >

Re: [swift-evolution] Feature proposal: Range operator with step

> For example, there are all kinds of other ways to slice this: > >stride(over: 0..<200, by: -2) This seems like a particularly good solution. The way I understand it at least, it would allow ranges to always be ordered, with the only difference being whether it went start-to-end or end-to-

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Xiaodi Wu wrote: > On Tue, Apr 5, 2016 at 4:28 PM, Dave Abrahams via swift-evolution > wrote: >> >> on Tue Apr 05 2016, Xiaodi Wu wrote: >> >>> Right. I would argue that `(a+s...b).striding(by: s).reversed` is a great >>> deal >>> less readable than `stride(from: b, to: a,

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Xiaodi Wu wrote: > I think my opinion is largely the same. A range is not a stride, I don't think anyone on this thread has suggested they could be considered the same... until just now. > and sometimes we have use for striding backwards, a use case that > shouldn't be pen

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Erica Sadun wrote: > On Apr 5, 2016, at 5:22 PM, Dave Abrahams via swift-evolution > wrote: > I don't think that's obvious at all, because 0 ≮ 10 > > Points brought up elsewhere: Sorry, I've tried, but I'm afraid I don't understand any of this: > * A range does

Re: [swift-evolution] Feature proposal: Range operator with step

I think people are reading a ..< b as the mathematical notation [a, b) which means {}, null, or empty, not error, if b < a and {a} if b = a. If Range was changed to be an Array like collection indexed from 0 to count and stride was how the indexed counted and was an Int > 0 then the following woul

Re: [swift-evolution] Feature proposal: Range operator with step

On Tue, Apr 5, 2016 at 4:28 PM, Dave Abrahams via swift-evolution wrote: > > on Tue Apr 05 2016, Xiaodi Wu wrote: > >> Right. I would argue that `(a+s...b).striding(by: s).reversed` is a great >> deal >> less readable than `stride(from: b, to: a, by: -s)`. And since the latter is >> the >> stat

Re: [swift-evolution] Feature proposal: Range operator with step

I think my opinion is largely the same. A range is not a stride, and sometimes we have use for striding backwards, a use case that shouldn't be penalized. +1 to the free function. I wouldn't mind, orthogonally, a way to express (a, b] as a range. It just seems like that should be of use, somewhere

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 5:22 PM, Dave Abrahams via swift-evolution > wrote: > I don't think that's obvious at all, because 0 ≮ 10 Points brought up elsewhere: * A range does not have direction, it is is an area of variation between lower and upper limits. * A range does not go from a larger amou

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Erica Sadun wrote: >> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Apr 05 2016, Erica Sadun wrote: >> > >>>On Apr 5, 2016, at 1:54 PM, Dave Abrahams >>> wrote: >>>IMO this: >>> >>>(-9...0).reverse() >>> >>>

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Stephen Canon wrote: > On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution > wrote: > > On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution > wrote: > > on Tue Apr 05 2016, Erica Sadun > wrote: > > O

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 4:24 PM, Stephen Canon wrote: > >> On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> on Tue A

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Xiaodi Wu wrote: > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams wrote: >> >> on Sat Apr 02 2016, Xiaodi Wu wrote: >> >>> [snip] >>> >>> Not included: >>> 1. I know Ranges are in flux, so I've held off on extending Range with >>> a striding(by:) method in this proof-of-conc

Re: [swift-evolution] Feature proposal: Range operator with step

Well, probably best to have another operator: 0..>(-10). We go from 0 to greater than -10. On Tue, Apr 5, 2016 at 5:22 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution > wrote: > >> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Tue Apr 05 2016, Erica Sadun wrote: >> >>> On Apr 5, 2016, at 1:54 PM, Dave Abrahams >>>wrote: >>> IMO this: >>> >>> (-9...

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 4:22 PM, Erica Sadun via swift-evolution > wrote: > >> >> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Apr 05 2016, Erica Sadun wrote: >> >>> On Apr 5, 2016, at 1:54 PM, Dave Abrahams >>>wrote: >>> IMO this: >>> >>>

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 05 2016, Erica Sadun wrote: > >>On Apr 5, 2016, at 1:54 PM, Dave Abrahams >> wrote: >>IMO this: >> >>(-9...0).reverse() >> >>is better than >> >>stride(from: 0, to: -10, by:

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Erica Sadun wrote: > On Apr 5, 2016, at 1:54 PM, Dave Abrahams > wrote: > IMO this: > > (-9...0).reverse() > > is better than > > stride(from: 0, to: -10, by: -1) > > What do you think? > > The latter better reflects an author's actual intent. Th

  1   2   >