I see your points and agree that this is a small feature. My thinking was that it can be added to the standard library pretty easily just because of this without real disadvantages – but it may of course not pay for itself and maybe even cause confusion.
As I stated earlier implementing the method also is about what the standard library should be and what it should not. I learned more about it now and understand that the suggested method may not be appropriate for it. I will probably stick with libraries for a `times` method in the future then. Thank you very much Radek, Chris and the others for your feedback and consideration! – Cihat > Am 18.12.2015 um 21:37 schrieb Chris Lattner <[email protected]>: > >> >> On Dec 18, 2015, at 12:32 PM, Radosław Pietruszewski <[email protected]> >> wrote: >> >>> >>> 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 >> >> Thanks for weighing in! >> >> The benefit of `5.times` vs `repeat 5` is that the former is (and can easily >> be) defined in Swift, not as a language-level feature. OTOH `repeat 5` is a >> bit more useful because it allows returning/breaking/etc. >> >> But I also understand the argument that this feature isn’t worth it at all. >> (There’s already a lot of libraries extending stdlib with things of this >> sort!) > > It’s important to differentiate “not interesting” vs “not appropriate to > include in the swift standard library”. I love that you can express things > like that directly in the language, and if someone felt compelled to do that > in their own code (or in a SPM package someday) that would be fine with me. > It just shouldn’t (again, IMO) come with swift out of the box. > > -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
