[swift-evolution] For-loop revisited

[Ted F.A. van Gaalen]

Hello Haravikk,

Thank you. Yes I know this is possible,
but my main point is that   for..in..    always expects an instance of some sort of a collection.

e.g for this for-loop:

for var x in -60.0.stride(to: 60.0, by:  0.001) 


What I don’t know: (can’t find yet)
>>  Will in this case a large collection with 120000 elements of Double be created by .stride?
 or
>>  Does .stride(), which in the end uses a descendant of SequenceType, just calculate a new value each time   for..in..   uses .next() on this collection? 
I hope the latter is true.  

Can someone clarify this perhaps? 

Still , I’d rather see a for variant with “from”

e.g.

    for  x from xmin to xmax by xstep  { }

    for x from xmax to xmin by -xstep  { } 

    for apple from 1 to applesInTruck  { }

No need for collections in these cases,

Shouldn't be that hard to implement? 

kind regards
Ted



ted van gaalen



> On 26.02.2016, at 12:45, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>> On 26 Feb 2016, at 02:11, ted van gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> for var n from 10 to 1 by -1  { }    //  looping backwards
> 
> This is currently possible with:
> 
> 	for var n in (1 … 10).reverse()
> 
> Which I find pretty simple personally, though being able to do 10 … 1 would be nice.
> 
>> for var n from -10 to 12   // here, the compiler assumes and increment value of 1, no "by" is needed.
> 
> The following already does this one as-is:
> 
> 	for var n in -10 … 12
> 
>> for var x: Float from -60.0 to 120 by 0.01 { }  // this one has many iterations!
>> for var d from 0.0 to abyss by -rate {} 
> 
> These two definitely make more of a case for this. I’m not so sure about introducing new keywords for this though.
> 
> Personally I think that what we need is a more flexible type for the … and ..< operators that is simple two related values in any order, which Range could be instantiated from with more strict conditions (must be low to high) for things like grabbing arrays slices and so-on where the order matters. The basic non-Range would then be optimised for use with loops to give us the greater flexibility without having to do stuff like using .reverse().
> 
> Plus ideally the new type would be capable of representing a full range of values; I really don’t like that Range<UInt8> is currently limited to 0-254 inclusive, since the endIndex is always exclusive, but that’s another topic really.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/5b698022/attachment.html>