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

[Chris Lattner]

> On Dec 18, 2015, at 12:19 PM, Radosław Pietruszewski <radexpl at gmail.com> wrote:
> 
>> 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?
> 
> Perhaps — there’s a thread, somewhere, with possible solutions to this.
> 
> FWIW, I’m just as concerned about allowing returning/etc in closures, as with the lack of this ability. Ruby has different forms of “closures”, far too many of them actually, and some of them truly act like functions (just like in Swift), and in some, return/etc changes the calling function. And… albeit useful… this can be _really_ confusing.
> 
>> Do you think `times` wouldn’t be useful enough with the closure restriction?
> 
> I’d still like it, but it’s just this tiny little thing. Swift standard library is currently very bare-bones, unlike, say, Ruby’s, which has *a ton* of stuff on Arrays, Strings, etc. Unless the Core Team is OK with expanding those standard types with more useful helper methods more broadly, there’s no reason why `times` in particular should go in.

My personal opinion on this is that 5.times { stuff} offers no benefits over “repeat 5 { stuff }”, so I’d rather see the later (if anything).

This is all shades of gray with no clear answer.  We generally want to have standard APIs pay for themselves and avoid confusion.  I agree with DaveA’s points upthread.  If you contrast it with forEach, forEach (barely!) pays for itself by allowing things like:

	collection.forEach(curriedMethod)

That benefit doesn’t translate to “.times".

-Chris