<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 26, 2017, at 01:14, Slava Pestov via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Ray,<div class=""><br class=""></div><div class="">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].</div><div class=""><br class=""></div><div class="">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’.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div>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 <i class="">want</i> that behavior, though.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>