Re: [swift-dev] C-style For Loops

2015-12-19 Thread Wallacy via swift-dev
> > Why? > Because this works: var rangeA = -150.0..<150 for lat in rangeA.by(30) { print(lat) } And this not: var rangeC = -150..<150 for lat in rangeC.by(30) { // Error - Value of type 'Range' has no member 'by' print(lat) } I think this is expected to work, or not? If you make a e

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Brent Royal-Gordon via swift-dev
> I personally liked the original free-function syntax—"stride(from: -50, to: > 50, by: 9)". When we got protocol extensions, we decided we'd prefer methods > everywhere except in a few special cases, and this clearly falls outside > those criteria. I don't know about that—in `stride(from: -50

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Dave Abrahams via swift-dev
> On Dec 19, 2015, at 2:24 PM, Brent Royal-Gordon > wrote: > >>> One practical reason is that interval.start must always be before >>> interval.end, so this makes striding in reverse difficult. >> >> We could declare that negative strides cause us to start at the end rather >> than at the st

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Brent Royal-Gordon via swift-dev
>> One practical reason is that interval.start must always be before >> interval.end, so this makes striding in reverse difficult. > > We could declare that negative strides cause us to start at the end rather > than at the start. I've noticed in the past that the Swift standard library does no

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Dave Abrahams via swift-dev
> On Dec 19, 2015, at 1:47 PM, Brent Royal-Gordon > wrote: > >>> for lat in (CGFloat(-60)...60).by(30) { >>> print(lat) >>> } >>> >>> for lat in (CGFloat(-60)..<60).by(30) { >>> print(lat) >>> } >> >> This is nice; why don't we put it in the standard library and get rid of the >> "stride"

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Dave Abrahams via swift-dev
> On Dec 19, 2015, at 1:20 PM, Wallacy wrote: > > Curiously I was analyzing this part of the library a few minutes ago. > It will probably be necessary to extend "Range": > > extension Range where Element: Strideable { > func by(n: Element.Stride) -> StrideThrough { > return startIn

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Brent Royal-Gordon via swift-dev
>> for lat in (CGFloat(-60)...60).by(30) { >> print(lat) >> } >> >> for lat in (CGFloat(-60)..<60).by(30) { >> print(lat) >> } > > This is nice; why don't we put it in the standard library and get rid of the > "stride" methods? One practical reason is that interval.start must always be befo

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Wallacy via swift-dev
Curiously I was analyzing this part of the library a few minutes ago. It will probably be necessary to extend "Range": extension Range where Element: Strideable { func by(n: Element.Stride) -> StrideThrough { return startIndex.stride(through: endIndex, by: n) } } The first thing t

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Dave Abrahams via swift-dev
> On Dec 19, 2015, at 11:44 AM, Donnacha Oisín Kidney via swift-dev > wrote: > > You can define an extension on interval types: > > extension HalfOpenInterval where Bound: Strideable { > func by(n: Bound.Stride) -> StrideTo { > return start.stride(to: end, by: n) > } > } > > extension

Re: [swift-dev] C-style For Loops

2015-12-19 Thread Donnacha Oisín Kidney via swift-dev
You can define an extension on interval types: extension HalfOpenInterval where Bound: Strideable { func by(n: Bound.Stride) -> StrideTo { return start.stride(to: end, by: n) } } extension ClosedInterval where Bound: Strideable { func by(n: Bound.Stride) -> StrideThrough { return st