> On Dec 18, 2015, at 12:19 PM, Radosław Pietruszewski <[email protected]>
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
