This thread: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001150.html
 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001150.html>

— Radek

> On 18 Dec 2015, at 21:40, Dennis Lysenko via swift-evolution 
> <[email protected]> wrote:
> 
> 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] 
> <mailto:[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] 
>> <mailto:[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] <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

Reply via email to