[swift-evolution] Proposal: Add .times method to Integer type
Jacob Bandes-Storch
jtbandes at gmail.com
Fri Dec 18 13:53:53 CST 2015
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/1fe71d40/attachment.html>
More information about the swift-evolution
mailing list