[swift-evolution] [Proposal] Conventionalizing stride semantics

Erica Sadun erica at ericasadun.com
Thu Mar 3 10:23:41 CST 2016


Should ranges drop that precondition then? So they can represent forward and backward progressions?

> On Mar 3, 2016, at 8:10 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Tue Mar 01 2016, Haravikk <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I still wonder if a better solution might involve the same syntax as ranges currently benefit from, i.e:
>> 
>> 	0 ..< 10 // [0, 10) with an increment of 1
>> 	(0 … 10).stride(2) // [0, 10] with an increment of 2
>> 
>> The most important change is that the default type for this should be able to handle higher starting indices, e.g:
>> 
>> 	(10 … 0).stride(2) // [10, 0] with a decrement of 2
> 
> I like this approach a lot.  We have lots of different ways to express
> variations on ranges and intervals today that don't actually involve the
> range operators (including prefixTo, suffixFrom, stride).  IMO they
> should.
> 
> The one problem I anticipate is that negative strides won't work well,
> because forming (a...b) will have a precondition that a <= b.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/8669102f/attachment.html>


More information about the swift-evolution mailing list