> 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. Jordan
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users