[swift-users] withoutActuallyEscaping example question

[Dave Abrahams]

on Mon Mar 27 2017, Jordan Rose <jordan_rose-AT-apple.com> wrote:

>> 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.

That seems like a worthy thought.

-- 
-Dave