[swift-evolution] Stdlib closure argument labels and parameter names

[Dave Abrahams]

on Mon Jun 27 2016, Patrick Smith <pgwsmith-AT-gmail.com> wrote:

> Side question: is there going to be any situation where I’m iterating
> through a sequence/collection that I wouldn’t want to always use
> `lazy`? Is `lazy` *always* going to be more efficient than the
> array-creating defaults when the result is iterated?

If all you're going to do is iterate over it at most once, then yeah,
the lazy version will pretty much always be more efficient.  If anything
you do with the lazy result makes multiple passes (including
constructing an array if it is a collection with O(N) count, like the
result of a lazy filter), then you have to be prepared for the closures
you use to be called multiple times.

> For instance, something much better than this terrible syntax:
>
> for a in sequence where .filter({ $0 > 5 }).map({ $0 * 2 })  {
>   print(a)
> }


I don't know what that's supposed to illustrate.

> It would be up to the compiler what calls it turns that into, possibly
> it could make a certain whitelist of transformations (filter, map) as
> efficient as using `for … where` or `guard` today? Or it could simply
> make use of `lazy`.
>
> `for` is already hiding ‘magic’ by calling `makeIterator()`, why can’t
> it do more ‘magic’, especially since `lazy` is a member of `Sequence`
> just like `makeIterator()`.
>
> Anyway, something for the future after Swift 3.0.

It's an interesting thought, yes.

-- 
Dave