@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] > <mailto:[email protected]>> wrote: > >> Am 18.12.2015 um 20:13 schrieb Félix Cloutier <[email protected] >> <mailto:[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] <mailto:[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 >>> <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] >>>> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
