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 <[email protected]> wrote: > > Am 18.12.2015 um 20:13 schrieb Félix Cloutier <[email protected]>: > > 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 < > [email protected]> 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: > http://ruby-doc.org/core-2.2.4/Integer.html#method-i-times > > 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 <[email protected]>: > > (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 < > [email protected]> 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 < > [email protected]> 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, > Cihat > > > P.S.: This is my very first mail in such a mailing list so I did > everything correctly. ^.^ > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
