[swift-evolution] Revisiting SE-0110

[Amit Jain]

In addition to dictionaries, In paradigms like Rx, this sugar helps immensely towards writing concise single-line transforms where one can quickly understand what the transform is trying to achieve. It is quite common to work with many arguments which are morphed as one moves down the chain. Adding boilerplate to every single closure in such places will be really noisy and regressive to clarity at the point of use. 

> > On May 24, 2017, at 6:18 PM, Ben Cohen via swift-evolution<swift-evolution at swift.org>wrote:
> > 
> > I very much agree with your concerns about this change in general.
> > 
> > On this specific example, though, I just wanted to point out that there doesn’t seem to be a good reason to use .forEach here.
> > 
> > for (key, value) in self {
> > // etc
> > }
> > 
> > Would work perfectly well and is clearer IMO, still works with destructing, doesn’t have gotcha problems related to continue/break not doing what you might expect, etc.
> > 
> > forEach is only really a win when used on the end of a chain of map/filter-like operations, where for…in would involve bouncing back from right to left.
> Furthermore, this probably comes up most commonly with dictionaries, since they're a sequence of tuples. The element tuple for dictionaries has element labels (key: Key, value: Value), so instead of writing `{ tuple in let (key, value) = tuple; f(key, value) }`, you could use the implicit argument and write `{ f($0.key, $0.value) }`.
> 
> -Joe
> 
> 
>