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@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-@escaping ‘predicate’.
>>
>> In the second example, ‘predicate’ is known to be non-@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
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
