Wow. Thanks for the explanation! I didn’t realize I was toggling between
different overloads but that makes sense now.
Thanks again,
Ray
PS: It is sort of a strange example in the first place (being lazy and then
immediately eager.) I don’t think it is a use case that is compelling enough
to consider overload resolution rules over.
> On Mar 26, 2017, at 1:21 AM, Slava Pestov <spes...@apple.com> wrote:
>
> Here’s another fun one: the following type checks despite the literal
> closure; we’ve constrained the return type of filter() to [Int], and not
> LazyFilterCollection<Int>, so again the type checker picks the overload that
> takes the non-escaping closure:
>
> func myFilter(array: [Int], predicate: (Int) -> Bool) -> [Int] {
> return array.lazy.filter { predicate($0) }
> }
>
> Slava
>
>> On Mar 26, 2017, at 1:14 AM, Slava Pestov via swift-users
>> <swift-users@swift.org <mailto: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.
>>
>> Slava
>>
>>> On Mar 26, 2017, at 12:13 AM, Ray Fix via swift-users
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> 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
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>
>> _______________________________________________
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
