I like how clean "100.times { doSomething() }" looks, but I'm concerned its
usefulness will be limited because control-flow statements like
break/continue/return won't work from inside a closure.
Jacob
···
On Fri, Dec 18, 2015 at 11:36 AM, Cihat Gündüz <swift-evolution@swift.org> wrote:
Am 18.12.2015 um 20:13 schrieb Félix Cloutier <felixcca@yahoo.ca>:
It doesn't need to be an underscore, but when it is not, the compiler
emits an educative warning steering you towards _:It’s not about the underscore as a character, it’s about the fact that
there is the clutter of an underscore at all what I don’t like and what
makes me feel the code isn’t as clean as it could be.*/tmp/test.swift:3:7: **warning: **immutable value 'i' was never used;
consider replacing with '_' or removing it*You can also use inclusive ranges instead if you're more comfortable with
that: 1...5000 will do just that.I’m comfortable with ranges but I also used to teach Java back a few years
ago and I saw computer science students struggle with the exact number a
loop was being executed. So that’s the only reason I brought up that
example to have an additional argument.But again, for me it is more about the clutter that the 1… or 0..< adds to
something that could so easily made simpler and more descriptive.I think this is also a question of: *How many convenience methods do we
want to see in the Swift standard library?* In Ruby, at least, there
seemed to be enough people to find this one useful. And it’s the first
method I missed until now, so I took that as a sign before suggesting the
addition. I also don’t like when there are thousands of convenience methods
for things that could easily be written in other ways – but I don’t feel
that way with the suggested .times method.I don't mean to come across as dismissive, and I'm all for an inclusive
Swift that you can pick up without knowing advanced concepts. However,
there is definitely value in helping people learn, and learning always
moves you a little bit out of your comfort zone. When do we remove the
training wheels? How long can we hide the fact that indices usually start
at 0? How long before you need to iterate an array using the same
range-based for loop?I spend a lot of time on Stack Overflow and I've seen lots of beginners
ask for lots of things, but the people who ask about the for loop are
usually people with a background in another C-like language who try to use
the arguably less readable C-like for loop. I've never seen anyone before
say that it looks unclean or unreadable.I understand what you mean but I don’t think that this is about indices or
beginners. The fact that readability and expressiveness make a language
easier to learn for beginners IMHO is just a side effect of a well
thought-out and developed language. Maybe I wasn’t clear enough but I want
to see the .times method in Swift for my own usage, not for beginners. :)Le 18 déc. 2015 à 13:38:59, Cihat Gündüz via swift-evolution < > swift-evolution@swift.org> a écrit :
I agree with both of you about the alternative implementations.
That’s exactly what I’d love to see integrated to the standard library
like Ruby is here:
Class: Integer (Ruby 2.2.4)My main problem is that it neither looks *clean* nor *readable* especially
for beginners that there is an *underscore* in the closure. Also
beginners often get confused with the number of times some code is run when
*starting to count from 0* which is also why I think it shouldn’t
appear. The .times method would solve both of these problems.Am 18.12.2015 um 19:33 schrieb Etan Kissling <kissling@oberon.ch>:
(or with a for in loop -- but i guess you have a reason for using
.foreach)for _ in 0..<5_000 {
print("asdf")
}On 18 Dec 2015, at 19:31, Etan Kissling via swift-evolution < > swift-evolution@swift.org> wrote:
You don't need stride for this.
func foo() {
(0..<5_000).forEach { _ in
print("asdf")
}
}On 18 Dec 2015, at 19:25, Cihat Gündüz via swift-evolution < > swift-evolution@swift.org> wrote:
Dear Swift-Community,
I’d like to propose an *addition of a useful method*, especially for
beginners that also makes Swift much more readable in some situations: The
addition of a .times method to Integer type(s).For example recently in one of my projects I wanted to test the
scalability of an important piece of code and wrote this method:func testPerfQualityInPercentWithoutQualityImprovements() {
self.measureBlock {
let expectedQuality = 33.33
0.stride(to: 5_000, by: 1).forEach { _ in
XCTAssertEqualWithAccuracy(self.crossword.qualityInPercent,
expectedQuality, accuracy: 0.1)
}
}
}As you can see what I basically wanted was to repeat the test some
thousand times. I also like to use the Ruby language and one thing I love
about it is that it has some really handy methods integrated to the
language in situations like this which make the code very readable and
therefore fun to use.I’m an even bigger fan of Swift so I’d love to see such useful methods
appear in Swift, too and this is the first I came across that I really
missed. So I’m asking myself, what if I could write the same code above
like this:func testPerfQualityInPercentWithoutQualityImprovements() {
self.measureBlock {
let expectedQuality = 33.33
5_000.times {
XCTAssertEqualWithAccuracy(self.crossword.qualityInPercent,
expectedQuality, accuracy: 0.1)
}
}
}I think it could be added to the Swift standard library very easily (for
example by using the .stride method like I used) without any side effects
and has enough advantages to be part of Swift itself. What do you think?I wish you all the best,
CihatP.S.: This is my very first mail in such a mailing list so I did
everything correctly. ^.^_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution