Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Apr 25, 2016, at 7:15 PM, Xiaodi Wu via swift-evolution wrote: > > Yup, we're going to try to touch base, the authors of the current draft that > is, sometime this week. More to come, hopefully. > > > On Mon, Apr 25, 2016 at 8:13 PM, Dave Abrahams via

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Yup, we're going to try to touch base, the authors of the current draft that is, sometime this week. More to come, hopefully. On Mon, Apr 25, 2016 at 8:13 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Dave Abrahams

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Mon Apr 11 2016, Dave Abrahams wrote: > on Sun Apr 10 2016, Michel Fortin wrote: > >> So if you take this into account, storing the comparator as part of >> the stride makes the cost more predictable: not only there is one >> branch less in `next()`, but you avoid

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I agree with Taras that stride() and .striding() should coexist. -Thorsten > Am 09.04.2016 um 01:01 schrieb Taras Zakharko via swift-evolution > : > > I am agnostic on a .striding() method, but I am strongly agains any > suggestions of removing/replacing the

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On Apr 11, 2016, at 6:49 PM, Dave Abrahams via swift-evolution > wrote: > > on Mon Apr 11 2016, Ross O'Brien wrote: > >> I think I'd like to +1 a 'for x in loop(from: while: next:)'. (Possibly >> 'iterate' rather than 'loop'?) > >

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Mon Apr 11 2016, Ross O'Brien wrote: > I think I'd like to +1 a 'for x in loop(from: while: next:)'. (Possibly > 'iterate' rather than 'loop'?) Maybe 'iterations'. It should be a noun, I think. > I've not missed the C-style for-loop so I've not argued to keep

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I think I'd like to +1 a 'for x in loop(from: while: next:)'. (Possibly 'iterate' rather than 'loop'?) I've not missed the C-style for-loop so I've not argued to keep it, but recently I was refactoring a function which started with a UIView and iterated up the hierarchy through the superview

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Mon Apr 11 2016, Michel Fortin wrote: > Le 11 avr. 2016 à 14:36, Dave Abrahams a écrit : > >> 3. The fact that we're migrating C-style for loops to >> uses of stride, as noted in https://github.com/apple/swift/pull/2125, >> has convinced me that, sadly, we may need

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 11 avr. 2016 à 14:36, Dave Abrahams a écrit : > 3. The fact that we're migrating C-style for loops to > uses of stride, as noted in https://github.com/apple/swift/pull/2125, > has convinced me that, sadly, we may need an answer that doesn't > involve ranges. But

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Fair enough. If we go this direction, there's little sense in conforming StrideTo and friends to Collection at the moment, I suppose? On Mon, Apr 11, 2016 at 9:56 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Xiaodi Wu

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Mon Apr 11 2016, Xiaodi Wu wrote: > I realize what follows is actually an argument for restricting stride to > collections with randomly accessible elements, and maybe we should: > > We've touched a little bit on performance, and I think my feeling with stride >

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I realize what follows is actually an argument for restricting stride to collections with randomly accessible elements, and maybe we should: We've touched a little bit on performance, and I think my feeling with stride is that just the name itself suggests a certain logic--namely, that we

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

ah, you're right about that! somehow there was a doubly linked list in my head, sorry. TedvG > On 11 Apr 2016, at 11:20, Haravikk wrote: > > >>> On 10 Apr 2016, at 22:44, Ted F.A. van Gaalen via swift-evolution >>> wrote: >>> >>> Say

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On 10 Apr 2016, at 22:44, Ted F.A. van Gaalen via swift-evolution > wrote: > >> Say you wanted to stride through a singly-linked list, it would actually be >> beneficial to support only forward strides, the same is true of sequences, >> as you either may not know

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On Apr 9, 2016, at 1:27 AM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Apr 9, 2016 at 5:44 AM, Wallacy via swift-evolution > wrote: >> Just as note, i think the sintax should be: >> >> 0...9 >> 0..<9 >> 0>..9 >> 0>.<9 I agree

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> Say you wanted to stride through a singly-linked list, it would actually be > beneficial to support only forward strides, the same is true of sequences, as > you either may not know what the endpoint is, or would have to step through > the whole sequence to find it (plus buffer every value in

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Sun, Apr 10, 2016 at 3:58 PM, Haravikk wrote: > > On 10 Apr 2016, at 14:25, Xiaodi Wu wrote: > > What types do you have in mind that would only support positive distances? > All numeric types (yes, even UInt, etc.) have signed distances, which

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Sun Apr 10 2016, Michel Fortin wrote: > Le 10 avr. 2016 à 6:17, Brent Royal-Gordon via swift-evolution > a écrit : > >> Remember, conditional branches are relatively slow, and we want to > avoid them where we can. If this is, for

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Sun Apr 10 2016, Brent Royal-Gordon wrote: >> I can’t imagine any scenario in which getting the step's sign wrong wouldn’t >> just be a typo. > > Well, it could be an error if you derive the stride by subtracting two > numbers, and the second number is

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On 10 Apr 2016, at 14:25, Xiaodi Wu wrote: > > What types do you have in mind that would only support positive distances? > All numeric types (yes, even UInt, etc.) have signed distances, which > reflects the basic mathematical abstraction of a number line. Say you

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

What types do you have in mind that would only support positive distances? All numeric types (yes, even UInt, etc.) have signed distances, which reflects the basic mathematical abstraction of a number line. A consistent behavior with signed distances is so important that we are currently

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 10 avr. 2016 à 6:17, Brent Royal-Gordon via swift-evolution a écrit : > Remember, conditional branches are relatively slow, and we want to avoid them > where we can. If this is, for instance, the test of a loop, the extra branch > is not a good thing. Perhaps

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> I can’t imagine any scenario in which getting the step's sign wrong wouldn’t > just be a typo. Well, it could be an error if you derive the stride by subtracting two numbers, and the second number is unexpectedly larger than the first. Of course, that makes it a *bug*, not a typo. > Why not

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> I can’t imagine any scenario in which getting the step's sign wrong wouldn’t > just be a typo. Well, it could be an error if you derive the stride by subtracting two numbers, and the second number is unexpectedly larger than the first. Of course, that makes it a *bug*, not a typo. > Why not

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

The iteration counter will be floating point and the iterator will break down after incrementing by one is no longer exactly representable. It has been made clear on this list that there is a strong preference that no floating point stride should degenerate into an infinite loop due to this issue.

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I understand (and agree with) 3/4 of that… Why do we want to prevent striding *to* an infinity? I mean, yeah it’ll take a long time to get there, but with the new floating point stride code, a floating point value will *eventually* “overflow” into infinity (or `iteration += 1` will overflow and

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

We will be proposing exactly that which you've put in parentheses, i.e. floating point types will get their own strides, and it will be a precondition failure to try to stride from or to infinity or nan :) On Sun, Apr 10, 2016 at 4:47 AM wrote: > It’s not a matter of

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Oh, right, we’re talking about Swift 3.0… I really need to get that up and running on my computer. > On Apr 9, 2016, at 8:58 PM, Dave Abrahams wrote: > > > on Sat Apr 09 2016, davesweeris-AT-mac.com wrote: > >>On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

It’s not a matter of floating point error accumulation… At least on my machine, once a Double hits +/-∞, there’s no way that I know of to get back to normal floating point numbers. That is to say, for *all* normal, finite values of x, "-Double.infinity + x" will just return “-inf". If x is to

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Yikes. Not too concerned about the infinite loop issue, as floating point strides when fixed to avoid error accumulation will necessarily enforce a finite number of steps. However, you're talking a regular, not-at-all-lazy Array being returned? That would be not good at all... On Sun, Apr 10,

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On Apr 9, 2016, at 5:58 PM, Haravikk via swift-evolution > wrote: > > >> On 9 Apr 2016, at 10:50, Xiaodi Wu > > wrote: >> >> But, ranges are useful for more than just stride, and so I would say it >> doesn't make

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

IMO, 9...0 is a non-starter. Especially with Range taking on the role of Interval, it's critical that they have no direction. Suppose you have two ranges, 0...9 and 9...0. Is 0...9 == 9...0? IMO, two countable ranges r0 and r1 are equal if, for value in r0, r1.contains(value) == true, and vice

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution > wrote: > > While I’m in favour of the basic idea I think the operator selection is too > complex, and I’m not sure about the need for negative strides. Really all I > want are the following: > > (0

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On 9 Apr 2016, at 10:50, Xiaodi Wu wrote: > > But, ranges are useful for more than just stride, and so I would say it > doesn't make sense to have an intrinsic direction for Range, which pointedly > has lowerBound and upperBound but not start and end. For sample, there

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 9 avr. 2016 à 13:23, Xiaodi Wu a écrit : > The sign of the stride size is already (in the current version of Swift) > evaluated in the stride generator/iterator; as written, it is evaluated every > time next() is called, but of course that is optimized away when

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

The sign of the stride size is already (in the current version of Swift) evaluated in the stride generator/iterator; as written, it is evaluated every time next() is called, but of course that is optimized away when possible. What we are proposing adds no additional logic to the loop. I can't see

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 9 avr. 2016 à 4:25, Xiaodi Wu a écrit : > Note that it's not possible to write 9...0. Once that is clear, it's > fairly intuitive (IMO) to look to the stride size for indicating the > direction in which we stride, since that is the only other value there > is. I know it's

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Indeed. It's noted under "design concerns" and, IMO, raises the bar for their addition. On Sat, Apr 9, 2016 at 12:05 PM Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote: > Re: "Completing the Swift 3 range operator suite" >

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Re: "Completing the Swift 3 range operator suite" The proposed operators (<.. and <.<) are not allowed by Swift 2.2 lexer grammar:

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I agree with 90% of your comment. But, ranges are useful for more than just stride, and so I would say it doesn't make sense to have an intrinsic direction for Range, which pointedly has lowerBound and upperBound but not start and end. For sample, there shouldn't be (0...9).contains(1) and

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

While I’m in favour of the basic idea I think the operator selection is too complex, and I’m not sure about the need for negative strides. Really all I want are the following: (0 ... 6).striding(by: 2) // [0, 2, 4, 6] x from 0 to 6 (0 ..< 6).striding(by: 2)

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Sat, Apr 9, 2016 at 5:44 AM, Wallacy via swift-evolution wrote: > Just as note, i think the sintax should be: > > 0...9 > 0..<9 > 0>..9 > 0>.<9 > > Because the intention is produce a number bigger than 0 (start). So greater > than zero less than nine. That's not

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Sat, Apr 9, 2016 at 2:49 AM, Michel Fortin wrote: > Le 8 avr. 2016 à 14:37, Erica Sadun via swift-evolution > a écrit : >> >> (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1] > > The above reads wrong to me. The expression has to be read

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Sat, Apr 9, 2016 at 1:00 AM, Brent Royal-Gordon wrote: >> We propose to introduce a striding(by:) method on the revised 3.0 Range type. > > I take it that we're taking an incremental approach here, Yes, other proposals are on their way to complement this one. > and

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Just as note, i think the sintax should be: 0...9 0..<9 0>..9 0>.<9 Because the intention is produce a number bigger than 0 (start). So greater than zero less than nine. Em sex, 8 de abr de 2016 22:50, Michel Fortin via swift-evolution < swift-evolution@swift.org> escreveu: > Le 8 avr. 2016

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 8 avr. 2016 à 14:37, Erica Sadun via swift-evolution a écrit : > > (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1] The above reads wrong to me. The expression has to be read differently depending on the tinny detail that is the sign of the step that comes last: *

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> We propose to introduce a striding(by:) method on the revised 3.0 Range type. I take it that we're taking an incremental approach here, and further steps like: * Adding new range operators * Making all collections Strideable * Unifying Range and IntervalType so we can stride over non-integers

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I am agnostic on a .striding() method, but I am strongly agains any suggestions of removing/replacing the global stride() function. The stride function does not pollute the global namespace as it is a universally useful construct (among others, for implementing classical iterating for loops),

[swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Draft here: https://gist.github.com/erica/a51a981ee0352235204692affa959307 Feedback solicited, both positive and negative. We've also got a related proposal about expanding ranges, which you can look at here