If you can think of reasons why it might be a can of worms, I'd love to
hear them. It'd be a nice tool to have in the toolchain.
Stephen
···
On Wed, Dec 9, 2015 at 9:41 AM, Jason Pollack via swift-evolution < swift-evolution@swift.org> wrote:
Solutions like this look reasonable, until you try to use normal control
flow statements as you would in other loops. In the closure, a break or
continue are illegal, and a return acts like a continue.
var ok = true
5.times {
ok = someTest()
if (!ok) {
//break - Nope!
return //Sure, but loop continues anyway
}
}
Sure, it's a contrived example, but it's easy to see how this construct is
not like other loops.
On the other hand, it might be nice to be able to decorate a closure such
that break and continue behave as one might expect inside a loop, but that
sounds like a can of worms.
On Dec 9, 2015, at 12:58 PM, Tyler Cloutier via swift-evolution <swift-evolution@swift.org> wrote:
I’m still of the belief that all types of loops could be condensed down to a single type of loop, the repeat-for loop
Consider:
The for-in loop:
repeat for x in 0..<5 {
// code
}
The C style for loop and the while loop:
repeat for var i = 0 while someCondition(i) {
// code
}
The repeat while:
repeat for var i = 0 {
// code
} while someConditionEvaluatedAfterFirstLoop() // The i variable would likely have to be considered in scope in the while expression
The currently discussed repeat loop
repeat 5 {
// code
}
All follow a very basic pattern: The repeat keyword followed by a for declaration of loop scoped variables, then either a condition in the case of while or an iterator in the case of for-in. Optionally the language could include an “always” keyword that would specify a set of statements that were guaranteed to execute after each run of the loop. For example:
repeat for var i = 0 while i < 5 {
} always i += 1
If this were the case then all current loop constructs and their features could be subsumed by a single type of loop (including the to-be-removed C style for). This does have the problem of increasing the length of some current loop constructs though, specifically for-in.
Tyler
On Dec 8, 2015, at 10:05 PM, André Videla via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
How about having a default implementation in the standard library for it?
We avoid syntactic sugar and we allow for this very simple yet useful expression.
And we’ve seen solutions in this thread using autoclosurses and extensions
5.times {
…
}
or a function
repeat(4) {
…
}
all sound good to me.
- André
On 09 Dec 2015, at 06:58, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 8, 2015, at 4:43 PM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
For me this comes up when teaching children or new programmers. (Perhaps not a valid use case)
This is a very valid use case.
FWIW, “repeat N {}” was originally designed and scoped into the Swift 2 implementation of the feature, but was cut due to schedule limitations. There is precedent for this sort of feature in many teaching oriented languages (e.g. Logo).
I’d say that the pro’s and con’s of this are:
+ Makes a simple case very simple, particularly important in teaching.
+ Even if you aren’t familiar with it, you can tell at first glance what the behavior is.
- It is “just syntactic sugar”, which makes the language more complex.
- It is a very narrow feature that is useful in few practical situations.
On Dec 9, 2015, at 1:20 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:
This seems like the most sensible thing to me - if you don’t need the variable, just leave it out! Nice and clean and no confusion.
l8r
Sean
On Dec 9, 2015, at 3:18 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
for x in 1...5 {
… some code…
}
for x in 1…5 - what does 1 … 5 mean? What does it mean for x to be in 1 … 5? Now you tell me x isn’t in 1 … 5 and I can replace x with _ what does it mean for _ to be in 1 … 5 and why do I need _ at all? _ isn’t in the loop either. What’s a loop?
You know, I look at this and wonder, why can’t you just say `for 1…5`?
Sure, but the same is true of `for _ in 1…5`. The way I see it, this allows you to start by introducing “here’s how you do something five times”:
for 1…5 {
print(“Hello!”)
}
And then extend the very same syntax to “here’s how you find out which time you’re on”:
for i in 1…5 {
print(“Hello \(i)!”)
}
And from there, you can talk about how `1…5` can have different starting and ending points, can be a list of values instead of a series of numbers, etc. Seems like a nice way to make sure that learners *start* by using the same construct they’ll *finish* with.
Those ranges are the same length and basic math would tell you that. I don’t think it’d be that big a deal. In a learning context, you wouldn’t teach it that way anyway and the students who tried it would probably end up feeling clever.
Anyway, if Swift-for is to be modified, I’d say my desire would be for the following forms:
for (range) {}
for (thing) in (range) {}
for (thing) in (range) where (stuff) {}
for (any of the above) {} else {}
Multidimensional support also seems awesome, but I could live without it. (Well okay, I could live without any of this.. but you know what I mean. :P)
l8r
Sean
···
On Dec 9, 2015, at 3:21 PM, Tyler Cloutier <cloutiertyler@aol.com> wrote:
So, maybe it would be better to make "break" and "continue" behave like "break" and "next" in Ruby and enable non local return?
Then we would not need new syntax for new control structures but could create them as needed within the language.
-Thorsten
···
Am 14.12.2015 um 12:26 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:
Why not define a times() or timesRepeat() method on Int taking a closure to execute multiple times, like Erica recently posted and which is common in other languages like Ruby, Smalltalk or (I think) Scala:
In the teaching context, the answer is because it doesn’t actually teach you anything that can be extended to other parts of the language. `times` is a great fit for Ruby because many other Ruby looping constructs are also methods on an object (particularly the `each` loop), and because it works with all the usual loop flow control like `break`. None of these things are true about Swift, so you’re effectively teaching your students a dead end.
Neat, I was thinking something along the same lines. My 'can of worms'
thought is that it might be hard to distinguish between local and non-local
break/continue, and if the closure were a standalone function, would the
syntax even work? (I have an idea on this, but this ought to be a different
thread.) But I agree, would be a very nice tool to have.
···
On Wed, Dec 9, 2015 at 10:02 AM, Stephen Celis <stephen.celis@gmail.com> wrote:
On Dec 9, 2015, at 12:58 PM, Tyler Cloutier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’m still of the belief that all types of loops could be condensed down to a single type of loop, the repeat-for loop
Consider:
The for-in loop:
repeat for x in 0..<5 {
// code
}
The C style for loop and the while loop:
repeat for var i = 0 while someCondition(i) {
// code
}
The repeat while:
repeat for var i = 0 {
// code
} while someConditionEvaluatedAfterFirstLoop() // The i variable would likely have to be considered in scope in the while expression
The currently discussed repeat loop
repeat 5 {
// code
}
All follow a very basic pattern: The repeat keyword followed by a for declaration of loop scoped variables, then either a condition in the case of while or an iterator in the case of for-in. Optionally the language could include an “always” keyword that would specify a set of statements that were guaranteed to execute after each run of the loop. For example:
repeat for var i = 0 while i < 5 {
} always i += 1
If this were the case then all current loop constructs and their features could be subsumed by a single type of loop (including the to-be-removed C style for). This does have the problem of increasing the length of some current loop constructs though, specifically for-in.
On Dec 8, 2015, at 10:05 PM, André Videla via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
How about having a default implementation in the standard library for it?
We avoid syntactic sugar and we allow for this very simple yet useful expression.
And we’ve seen solutions in this thread using autoclosurses and extensions
On 09 Dec 2015, at 06:58, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 8, 2015, at 4:43 PM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
For me this comes up when teaching children or new programmers. (Perhaps not a valid use case)
This is a very valid use case.
FWIW, “repeat N {}” was originally designed and scoped into the Swift 2 implementation of the feature, but was cut due to schedule limitations. There is precedent for this sort of feature in many teaching oriented languages (e.g. Logo).
I’d say that the pro’s and con’s of this are:
+ Makes a simple case very simple, particularly important in teaching.
+ Even if you aren’t familiar with it, you can tell at first glance what the behavior is.
- It is “just syntactic sugar”, which makes the language more complex.
- It is a very narrow feature that is useful in few practical situations.
I actually tried to get an infinite loop this way once, after I saw that "repeat" was a keyword. It took me 10 minutes before I noticed the while after it was mandatory. Then I settled for "while true".
In case someone wants to fix the diagnostic message:
···
Le 9 déc. 2015 à 16:12, Tyler Cloutier via swift-evolution <swift-evolution@swift.org> a écrit :
+1 on ‘for 1…5 {‘. It seems intuitive when you already know for-ins, one look at it and you know what it does.Also, in a education setting, it seems easy to grasp and easy to then extend into more complicated for’s.
-1 for adding a new keyword like ‘repeat’. It seems way easier to keep fewer keywords, both for students and for programmers. I already don’t like the fact that we use both ‘for’ and ‘while’ to express loops (this was particularly vexing when I was learning CS) :/
···
On Dec 16, 2015, at 5:06 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:
So, maybe it would be better to make "break" and "continue" behave like "break" and "next" in Ruby and enable non local return?
Then we would not need new syntax for new control structures but could create them as needed within the language.
-Thorsten
Am 14.12.2015 um 12:26 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:
Why not define a times() or timesRepeat() method on Int taking a closure to execute multiple times, like Erica recently posted and which is common in other languages like Ruby, Smalltalk or (I think) Scala:
In the teaching context, the answer is because it doesn’t actually teach you anything that can be extended to other parts of the language. `times` is a great fit for Ruby because many other Ruby looping constructs are also methods on an object (particularly the `each` loop), and because it works with all the usual loop flow control like `break`. None of these things are true about Swift, so you’re effectively teaching your students a dead end.
loop for var i = 0 while someCondition(i) {
// code
}
loop for var i = 0 {
// code
} while someCondition(i) // The i variable would likely have to be considered in scope in the while expression
loop 5 {
// code
}
loop for var i = 0 while i < 5 {
// code
} always i += 1
···
On Dec 9, 2015, at 1:29 PM, Tyler Cloutier via swift-evolution <swift-evolution@swift.org> wrote:
Sorry, something is up with my email address.
Oooh and one more, the Infinite Loop:
repeat {
}
On Dec 9, 2015, at 12:58 PM, Tyler Cloutier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’m still of the belief that all types of loops could be condensed down to a single type of loop, the repeat-for loop
Consider:
The for-in loop:
repeat for x in 0..<5 {
// code
}
The C style for loop and the while loop:
repeat for var i = 0 while someCondition(i) {
// code
}
The repeat while:
repeat for var i = 0 {
// code
} while someConditionEvaluatedAfterFirstLoop() // The i variable would likely have to be considered in scope in the while expression
The currently discussed repeat loop
repeat 5 {
// code
}
All follow a very basic pattern: The repeat keyword followed by a for declaration of loop scoped variables, then either a condition in the case of while or an iterator in the case of for-in. Optionally the language could include an “always” keyword that would specify a set of statements that were guaranteed to execute after each run of the loop. For example:
repeat for var i = 0 while i < 5 {
} always i += 1
If this were the case then all current loop constructs and their features could be subsumed by a single type of loop (including the to-be-removed C style for). This does have the problem of increasing the length of some current loop constructs though, specifically for-in.
On Dec 8, 2015, at 10:05 PM, André Videla via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
How about having a default implementation in the standard library for it?
We avoid syntactic sugar and we allow for this very simple yet useful expression.
And we’ve seen solutions in this thread using autoclosurses and extensions
On 09 Dec 2015, at 06:58, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 8, 2015, at 4:43 PM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
For me this comes up when teaching children or new programmers. (Perhaps not a valid use case)
This is a very valid use case.
FWIW, “repeat N {}” was originally designed and scoped into the Swift 2 implementation of the feature, but was cut due to schedule limitations. There is precedent for this sort of feature in many teaching oriented languages (e.g. Logo).
I’d say that the pro’s and con’s of this are:
+ Makes a simple case very simple, particularly important in teaching.
+ Even if you aren’t familiar with it, you can tell at first glance what the behavior is.
- It is “just syntactic sugar”, which makes the language more complex.
- It is a very narrow feature that is useful in few practical situations.