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.
Slava
> On Mar 26, 2017, at 12:13 AM, Ray Fix via swift-users <[email protected]>
> wrote:
>
>
> Hi,
>
> One of the motivating examples for withoutActuallyEscaping looks like the
> following. This predictably doesn’t work because "use of non-escaping
> parameter 'predicate' may allow it to escape"
>
> func myFilter(array: [Int], predicate: (Int) -> Bool) -> [Int] {
> return Array(array.lazy.filter { predicate($0) })
> }
>
> The solution is to use withoutActuallyEscaping. This works and produces the
> expected results.
>
> func myFilter(array: [Int], predicate: (Int) -> Bool) -> [Int] {
> return withoutActuallyEscaping(predicate) { predicate in
> Array(array.lazy.filter({predicate($0)}))
> }
> }
>
> What I find puzzling is the below example compiles and runs correctly. It
> seems like it should be the same compiler error as in the first example.
>
> func myFilter(array: [Int], predicate: (Int) -> Bool) -> [Int] {
> return Array(array.lazy.filter(predicate))
> }
>
> If you understand why this is so, it would be very helpful.
>
> Thank you and best wishes,
> Ray
> _______________________________________________
> swift-users mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
