Proposal: Add .times method to Integer type


(Cihat Gündüz) #1

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. ^.^


(Brent Royal-Gordon) #2

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).

I’ve said it before, but I don’t think `times` is a good solution for learners. It teaches them a form of looping they will never use in practice and does not allow them to practice with ancillary loop skills like `break` and `continue`.

I think our best bet is to extend the `for` loop to allow a single number, meaning either `1…n` or `0..<n` (you can argue it either way), and also to allow the `variableName in` part to be omitted, meaning `_ in`. This gives us the pedagogical simplicity of a “do this N times” loop, but couches it in a form where, when the student moves on, more commonly used loop forms are a straightforward extension of that simple case.

  for 5 { print(“Hello!”) }
  for i in 5 { print(“Hello \(i)!”) }
  for i in 10..<20 { print(“Hello \(i)!”) }
  for i in 10...20 { print(“Hello \(i)!”) }

···

--
Brent Royal-Gordon
Architechies


(Jacob Bandes-Storch) #3

This can be done pretty easily, although I think the approach has the
potential to cause confusion elsewhere in code. An obvious question is,
should it be equivalent to 1...n, or 0..<n?

extension Int: SequenceType {
    public func generate() -> RangeGenerator<Int> {
        return (0..<self).generate()
    }
}

for i in 5 {
    print("hello \(i)")
}

Jacob Bandes-Storch

···

On Fri, Dec 18, 2015 at 1:03 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> 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).

I’ve said it before, but I don’t think `times` is a good solution for
learners. It teaches them a form of looping they will never use in practice
and does not allow them to practice with ancillary loop skills like `break`
and `continue`.

I think our best bet is to extend the `for` loop to allow a single number,
meaning either `1…n` or `0..<n` (you can argue it either way), and also to
allow the `variableName in` part to be omitted, meaning `_ in`. This gives
us the pedagogical simplicity of a “do this N times” loop, but couches it
in a form where, when the student moves on, more commonly used loop forms
are a straightforward extension of that simple case.

        for 5 { print(“Hello!”) }
        for i in 5 { print(“Hello \(i)!”) }
        for i in 10..<20 { print(“Hello \(i)!”) }
        for i in 10...20 { print(“Hello \(i)!”) }

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Félix Cloutier) #4

You can already write this:

extension IntegerType {
  func times(block: () -> ()) {
    for _ in 0..<self {
      block()
    }
  }
}

10.times { print("hello") }

I don't know how I feel about adding that to the standard library.

···

Le 18 déc. 2015 à 13:25:59, Cihat Gündüz via swift-evolution <swift-evolution@swift.org> a écrit :

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kenny Leung) #5

I don’t agree with this on the grounds that it isn’t very object-oriented. That is, it does not conform with what one usually associates with an integer. A number has certain intrinsic properties: 5 is greater than 4 but less than 6. If you’re a synesthete, it may have the color blue. But I never think of there being a big number 5 that takes something and repeats it 5 times. I think of a person taking something and doing it over 5 times.

-Kenny

···

On Dec 18, 2015, at 10:25 AM, Cihat Gündüz via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Lily Ballard) #6

-1 here. It provides almost no utility outside of "hello world" style
sample code. Also this particular method is ambiguous, as people have
already said (the word "times" can mean multiplication just as much as
it can mean looping), and it also doesn't even make much sense when used
with non-literals, e.g. "foo.count.times" does not have the same "sounds
like English" behavior that "5.times" does. More generally, we shouldn't
be adding stuff to the standard library that doesn't provide any clear
benefit, both because it's API bloat and because everybody has to pay
for the code size.

-Kevin Ballrd

···

On Fri, Dec 18, 2015, at 10:25 AM, Cihat Gündüz via swift-evolution 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 .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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Etan Kissling) #7

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@swift.org<mailto:swift-evolution@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@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Etan Kissling) #8

(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@swift.org<mailto:swift-evolution@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@swift.org<mailto:swift-evolution@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@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Cihat Gündüz) #9

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Radek Pietruszewski) #10

An obvious question is, should it be equivalent to 1...n, or 0..<n?

I think that’s exactly why this isn’t a good idea. The semantics of `for i in 5` are not immediately clear at all.

If this was to be a language feature, `repeat 5`, suggested by Chris, seems like the least-ambiguous choice.

— Radek

···

On 18 Dec 2015, at 22:09, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

This can be done pretty easily, although I think the approach has the potential to cause confusion elsewhere in code. An obvious question is, should it be equivalent to 1...n, or 0..<n?

extension Int: SequenceType {
    public func generate() -> RangeGenerator<Int> {
        return (0..<self).generate()
    }
}

for i in 5 {
    print("hello \(i)")
}

Jacob Bandes-Storch

On Fri, Dec 18, 2015 at 1:03 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 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).

I’ve said it before, but I don’t think `times` is a good solution for learners. It teaches them a form of looping they will never use in practice and does not allow them to practice with ancillary loop skills like `break` and `continue`.

I think our best bet is to extend the `for` loop to allow a single number, meaning either `1…n` or `0..<n` (you can argue it either way), and also to allow the `variableName in` part to be omitted, meaning `_ in`. This gives us the pedagogical simplicity of a “do this N times” loop, but couches it in a form where, when the student moves on, more commonly used loop forms are a straightforward extension of that simple case.

        for 5 { print(“Hello!”) }
        for i in 5 { print(“Hello \(i)!”) }
        for i in 10..<20 { print(“Hello \(i)!”) }
        for i in 10...20 { print(“Hello \(i)!”) }

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Cihat Gündüz) #11

As far as I can remember it was never a goal of Swift to be a purely object-oriented language. Instead I can find expressiveness stated explicitly amongst the three main goals behind the language here: https://swift.org/about/#platform-support

Therefore I feel it is okay if the language becomes more expressive in a way that is less object-oriented. I see the suggested method as a functional construct.

– Cihat

···

Am 18.12.2015 um 23:22 schrieb Kenny Leung <kenny_leung@pobox.com>:

I don’t agree with this on the grounds that it isn’t very object-oriented. That is, it does not conform with what one usually associates with an integer. A number has certain intrinsic properties: 5 is greater than 4 but less than 6. If you’re a synesthete, it may have the color blue. But I never think of there being a big number 5 that takes something and repeats it 5 times. I think of a person taking something and doing it over 5 times.

-Kenny

On Dec 18, 2015, at 10:25 AM, Cihat Gündüz via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #12

-1 as well. This Int extension is super-easy to implement if you want it. I don't remember ever using it in code outside tutorials.

"What ought to be in the standard C++ library? One ideal is for a programmer to be able to find every interesting, significant, and reasonably general class, function, template, etc., in a library. However, the question here is not, "What ought to be in some library?" but "What ought to be in the standard library?" The answer "Everything!" is a reasonable first approximation to an answer to the former question but not the latter. A standard library is something every implementer must supply so that every programmer can rely on it" -- B. Strustroup

Would including this proposal in the Standard Library make a programmer's job easier? Probably, but not often
Does this proposal represent a fundamental element of daily development tasks? In my opinion, no
Does this proposal extend the core functionality of the language? No
Does this proposal deserve a place in an expended Standard Library? No.
-- E

···

On Dec 18, 2015, at 4:18 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:

-1 here. It provides almost no utility outside of "hello world" style sample code. Also this particular method is ambiguous, as people have already said (the word "times" can mean multiplication just as much as it can mean looping), and it also doesn't even make much sense when used with non-literals, e.g. "foo.count.times" does not have the same "sounds like English" behavior that "5.times" does. More generally, we shouldn't be adding stuff to the standard library that doesn't provide any clear benefit, both because it's API bloat and because everybody has to pay for the code size.

-Kevin Ballrd

On Fri, Dec 18, 2015, at 10:25 AM, Cihat Gündüz via swift-evolution 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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #13

I guess everyone agrees that it is easy to add the functionality with an extension — and I'm quite sure many will do so.
For me, the need to add the method on my own (if I want to use it) is not an issue, but imho having several thousand implementations of the same concept isn't that appealing.
Tiny methods like "times" should be inlined anyways, so it actually doesn't matter, but for types and bigger functions, standardization would be a good thing:
C++ for example might have seen many thousand incompatible implementations of basic concepts like "point", "vector", "either" or "picture", most of them nearly identical and only created because there was nothing to build on.
It is a bad idea to put every possible concept into the standard lib, which imho should be as small and compact as possible, but looking at C++ again, there is boost…

So for me it would make sense to have a set of "semi"-standard libs to ensure that there is some consensus on common datatypes (especially protocols).
Right now, the Cocoa libs help us with things like CGSize, NSDate and UIImage, but I think this fundament is not the best choice for Swift on other platforms.

How about proposing to start adding some more official git-repositories for libs? That would be a much bigger thing than adding "Int.times", but as with boost, it could easily evolve alongside core Swift.

Tino


(Félix Cloutier) #14

It doesn't need to be an underscore, but when it is not, the compiler emits an educative warning steering you towards _:

/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 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.

···

Le 18 déc. 2015 à 13:38:59, Cihat Gündüz via swift-evolution <swift-evolution@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@oberon.ch <mailto:kissling@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Radek Pietruszewski) #15

I’m +1. It’s not something that’s super common, but `100.times { … }` expresses the intention far better than the rather cryptic `for _ in 0..<100 { … }`.

The only possible concern — and this has been expressed in the proposal to remove `forEach` — is that closures have different semantics than `for`. Mostly, if someone wants to return from a containing function, you can’t do that from a closure.

— Radek

···

On 18 Dec 2015, at 19:38, Cihat Gündüz via swift-evolution <swift-evolution@swift.org> wrote:

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@oberon.ch <mailto:kissling@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Radek Pietruszewski) #16

Who says it’s useful only for beginners?

The way I see it, it’s about expressivity. What conveys the intention better when you want to do something 10 times? `10.times { … }` or an iteration over a range from 0 to 10?

— Radek

···

On 18 Dec 2015, at 20:13, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

It doesn't need to be an underscore, but when it is not, the compiler emits an educative warning steering you towards _:

/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 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.

Le 18 déc. 2015 à 13:38:59, Cihat Gündüz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@oberon.ch <mailto:kissling@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Cihat Gündüz) #17

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. :slight_smile:

···

Am 18.12.2015 um 20:13 schrieb Félix Cloutier <felixcca@yahoo.ca>:

Le 18 déc. 2015 à 13:38:59, Cihat Gündüz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@oberon.ch <mailto:kissling@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Cihat Gündüz) #18

I agree with Radek. I find `for i in 5 { doSomething() }` or `for 5 { doSomething() }` to be very confusing since it is neither close to human language nor to any common programming language I know of.

I like the idea of giving students a step by step introduction into things, but this is IMO not the right way/place to do that.

– Cihat

···

Am 18.12.2015 um 22:26 schrieb Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org>:

An obvious question is, should it be equivalent to 1...n, or 0..<n?

I think that’s exactly why this isn’t a good idea. The semantics of `for i in 5` are not immediately clear at all.

If this was to be a language feature, `repeat 5`, suggested by Chris, seems like the least-ambiguous choice.

— Radek

On 18 Dec 2015, at 22:09, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This can be done pretty easily, although I think the approach has the potential to cause confusion elsewhere in code. An obvious question is, should it be equivalent to 1...n, or 0..<n?

extension Int: SequenceType {
    public func generate() -> RangeGenerator<Int> {
        return (0..<self).generate()
    }
}

for i in 5 {
    print("hello \(i)")
}

Jacob Bandes-Storch

On Fri, Dec 18, 2015 at 1:03 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 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).

I’ve said it before, but I don’t think `times` is a good solution for learners. It teaches them a form of looping they will never use in practice and does not allow them to practice with ancillary loop skills like `break` and `continue`.

I think our best bet is to extend the `for` loop to allow a single number, meaning either `1…n` or `0..<n` (you can argue it either way), and also to allow the `variableName in` part to be omitted, meaning `_ in`. This gives us the pedagogical simplicity of a “do this N times” loop, but couches it in a form where, when the student moves on, more commonly used loop forms are a straightforward extension of that simple case.

        for 5 { print(“Hello!”) }
        for i in 5 { print(“Hello \(i)!”) }
        for i in 10..<20 { print(“Hello \(i)!”) }
        for i in 10...20 { print(“Hello \(i)!”) }

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Cihat Gündüz) #19

By the way and/or for all of you who like the idea of a .times method:

I’ve just setup a library for features like this `times` method and implemented the suggested method there. Feel free to contribute code / provide feedback via that third party library (as suggested by Chris) here:

https://github.com/Flinesoft/HandySwift

– Cihat

···

Am 18.12.2015 um 23:42 schrieb Cihat Gündüz via swift-evolution <swift-evolution@swift.org>:

As far as I can remember it was never a goal of Swift to be a purely object-oriented language. Instead I can find expressiveness stated explicitly amongst the three main goals behind the language here: https://swift.org/about/#platform-support

Therefore I feel it is okay if the language becomes more expressive in a way that is less object-oriented. I see the suggested method as a functional construct.

– Cihat

Am 18.12.2015 um 23:22 schrieb Kenny Leung <kenny_leung@pobox.com <mailto:kenny_leung@pobox.com>>:

I don’t agree with this on the grounds that it isn’t very object-oriented. That is, it does not conform with what one usually associates with an integer. A number has certain intrinsic properties: 5 is greater than 4 but less than 6. If you’re a synesthete, it may have the color blue. But I never think of there being a big number 5 that takes something and repeats it 5 times. I think of a person taking something and doing it over 5 times.

-Kenny

On Dec 18, 2015, at 10:25 AM, Cihat Gündüz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Félix Cloutier) #20

The Foundation <https://github.com/apple/swift-corelibs-foundation> framework is being ported to other platforms and it has CGSize and NSDate (but not NSImage/UIImage). For the rest, the Swift package manager <https://github.com/apple/swift-package-manager> will probably fulfill that role, no?

···

Le 20 déc. 2015 à 06:09:19, Tino Heth via swift-evolution <swift-evolution@swift.org> a écrit :

I guess everyone agrees that it is easy to add the functionality with an extension — and I'm quite sure many will do so.
For me, the need to add the method on my own (if I want to use it) is not an issue, but imho having several thousand implementations of the same concept isn't that appealing.
Tiny methods like "times" should be inlined anyways, so it actually doesn't matter, but for types and bigger functions, standardization would be a good thing:
C++ for example might have seen many thousand incompatible implementations of basic concepts like "point", "vector", "either" or "picture", most of them nearly identical and only created because there was nothing to build on.
It is a bad idea to put every possible concept into the standard lib, which imho should be as small and compact as possible, but looking at C++ again, there is boost…

So for me it would make sense to have a set of "semi"-standard libs to ensure that there is some consensus on common datatypes (especially protocols).
Right now, the Cocoa libs help us with things like CGSize, NSDate and UIImage, but I think this fundament is not the best choice for Swift on other platforms.

How about proposing to start adding some more official git-repositories for libs? That would be a much bigger thing than adding "Int.times", but as with boost, it could easily evolve alongside core Swift.

Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution