It's a bit tangential but has there been any discussion about inlining closures that anyone is aware of? So you could return from the outer function within a closure, or break the outer loop.
On Fri, Dec 18, 2015, 3:09 PM Cihat Gündüz <[email protected]> wrote: > @Jacob, @Radek: Seems like you’ve found a clear restriction to the methods > usefulness given a simple implementation. You are right, of course. But > isn’t that more a sign that Swift needs a way to make closures more useful > by adding the possibility of breaking/continueing/returning from within > them rather than a disadvantage of the `times`-syntax itself? > > I mean, I find the closure-solution useful already. But if > break/continue/return would work from within the curly braces somehow > (either by a non-closure-based implementation like for-in loops or via a > future addition of some kind of strong/weak return etc.) then I agree that > it would be even more useful. > > Do you think `times` wouldn’t be useful enough with the closure > restriction? > > > > Am 18.12.2015 um 20:53 schrieb Jacob Bandes-Storch <[email protected]>: > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
