[swift-users] withoutActuallyEscaping example question

[Jordan Rose]

> On Mar 26, 2017, at 01:14, Slava Pestov via swift-users <swift-users at swift.org> wrote:
> 
> Hi Ray,
> 
> There are two overloads of filter() available on ‘array.lazy’; the version that takes an escaping closure and returns a LazyFilterCollection, and the version that takes a non-escaping closure and returns [Int].
> 
> In the first example, we pick the LazyFilterCollection-returning overload, because the literal closure { predicate($0) } can be coerced to both an escaping or a non-escaping closure type, and in the absence of additional constraints we go with the overload from a concrete type over an overload in a protocol extension. After the overload has been picked we validate the body of the closure, and notice that it is invalid because whole the closure is already known to be @escaping, it references the non- at escaping ‘predicate’.
> 
> In the second example, ‘predicate’ is known to be non- at escaping, which rules out the first overload completely, so we go with the second overload and perform a non-lazy filter.
> 
> I would argue this is somewhat confusing, but it might be difficult to change the overload resolution rules in a way where the first overload is always chosen.

It seems like we could just not take escaping-ness into account at all, and only diagnose if it mismatches. We'd have to decide if we want that behavior, though.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170327/08f83b81/attachment.html>