[swift-evolution] Proposal: Add .times method to Integer type

Dennis Lysenko dennis.s.lysenko at gmail.com
Fri Dec 18 14:40:12 CST 2015 

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 <swift-evolution at swift.org>
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 <jtbandes at gmail.com>:
>
> 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 at swift.org>
>  wrote:
>
>>
>> Am 18.12.2015 um 20:13 schrieb Félix Cloutier <felixcca at 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 at 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:
>> 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 <kissling at 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 at 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 at 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,
>> Cihat
>>
>>
>> P.S.: This is my very first mail in such a mailing list so I did
>> everything correctly. ^.^
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/9bf3a815/attachment.html>

More information about the swift-evolution mailing list