[swift-evolution] For-loop revisited

[Vanderlei Martinelli]

Well... I'm against the removal of C style for loop, but it is gone. (I do
not think the `for ... in ...`  is a replacement.) And I'm against the
removal of `++` and `--` operator as well. For years to come whenever
anyone asks me about it I'm going to say that I was against the removal. ;-)

I like the `for ... from ... to .. by ...` syntax. This would be a
replacement for the C style loop, not the `for ... in ... ` that, as I see,
is a very welcome addition but not a replacement.

-Van

On Fri, Feb 26, 2016 at 1:07 PM, Ted F.A. van Gaalen via swift-evolution <
swift-evolution at swift.org> wrote:

> 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> 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.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/0d925bbd/attachment.html>