<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 13, 2016, at 8:37 PM, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I am in the process of updating to Xcode 8 release so I can't confirm at the moment but I am fairly sure I hit a situation with being asked to implement a func from a protocol that got autocompleted with @escape nested as shown. It would then of course complain that wasn't valid. If I fixed it I don't think it was considered being implemented (it could only be an issue as noted in my prior thread related to default implementation not being picked up).<div class=""><br class=""></div><div class="">I will start a discussion about @escaping on the evolution list (hopefully soon). The main issue I see – beyond quirks like this – is that the proposal stated that closures would become noescape by default. </div></div></div></blockquote><div><br class=""></div><div>Link for those following along at home: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md</a></div><div><br class=""></div><div>Practically every occurrence of the word “closure” is immediately proceeded by “argument” or “argument to function”. Thus, it does not apply to stored members of structs, enum payloads, etc. I don’t like this either, but that is the current situation. Additionally, withoutActuallyEscaping is not implemented yet either, though I am looking into that.</div><div><br class=""></div><div>This gets muddy and non-intuitive very quickly, especially with syntactic sugar and the overall prevalence of optionals (especially when importing from ObjC!). In a pure Swift world, the most effective workaround (though I haven’t tested this myself) if one wants non-escaping optional closure arguments, is to use function overloading for the interface, but that’s not particularly fun (although withoutActuallyEscaping could help a tiny bit). In a mixed world, there is outright breakage around the seams, and I’m investigating what all the issues there are (I suspect many are compiler bugs, rather than language bugs).</div><div><br class=""></div><div>I would be in favor (and can help you champion) an escaping rule that propagates through generic parameters and non-nominal-type members. </div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I had existing code that applied @noescape against optional closures as well as tuples with closures, etc. which was happy and appeared to honor @noescape. I had expected closures in all "constructs" to be considered noescape after this change (what I got from reading the proposal) however in some situations they are considered escaping now when in fact in the past @noescape was able to be applied to state otherwise. It is possible that @noescape wasn't actually doing anything in those cases but it seemed like it was working to me.</div><div class=""><br class=""></div><div class="">So now I have code that I can't make work since it was meant to be noescape yet it is now considered escaping implicitly. If I try to fix this code I get complaints about things expected to escape and/or things needed to not escape (hard to explain with examples). I can likely rework the code to get it working again but expect to lose some of the desired implementation.</div><div class=""><br class=""></div><div class="">-Shawn</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Sep 13, 2016 at 8:16 PM Michael Ilseman <<a href="mailto:milseman@apple.com" class="">milseman@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On Sep 13, 2016, at 8:14 PM, Rick Mann <<a href="mailto:rmann@latencyzero.com" target="_blank" class="">rmann@latencyzero.com</a>> wrote:<br class="">
><br class="">
> But the Apple declaration (accessible via Xcode) of the method it's based on looks like this:<br class="">
><br class="">
> open func enumerator(at url: URL,<br class="">
> includingPropertiesForKeys keys: [URLResourceKey]?,<br class="">
> options mask: FileManager.DirectoryEnumerationOptions = [],<br class="">
> errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)<br class="">
> -> FileManager.DirectoryEnumerator?<br class="">
><br class="">
> handler is optional, but has @escaping. Is this an artifact of how Xcode presents system header files?<br class="">
><br class="">
<br class="">
That’s certainly funky. Might be that or a bug in the AST printer.<br class="">
<br class="">
><br class="">
>> On Sep 13, 2016, at 20:11 , Michael Ilseman <<a href="mailto:milseman@apple.com" target="_blank" class="">milseman@apple.com</a>> wrote:<br class="">
>><br class="">
>> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar for Optional<T>, and the noescape-by-default rule only applies to types in immediate parameter position. Current Swift master has much better diagnostics for this case.<br class="">
>><br class="">
>> There is not currently a general solution involving escapability of closure types used a generic parameters or tuple members, though such a thing would be useful in Swift 4.<br class="">
>><br class="">
>>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users <<a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a>> wrote:<br class="">
>>><br class="">
>>> The following is the earlier thread I was talking about.<br class="">
>>><br class="">
>>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping<br class="">
>>><br class="">
>>> -Shawn<br class="">
>>><br class="">
>>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson <<a href="mailto:shawnce@gmail.com" target="_blank" class="">shawnce@gmail.com</a>> wrote:<br class="">
>>> I hit this issue as well. I had an early email on this list regarding do this topic, not in a situation to search for it. It is a short coming in how escaping can be applied to things like optional closures.<br class="">
>>><br class="">
>>> I was in the process of authoring an email for swift evolution about it and haven't yet gotten around to filing a defect about it.<br class="">
>>><br class="">
>>> -Shawn<br class="">
>>> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users <<a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a>> wrote:<br class="">
>>> I'm trying to write this function. The errorHandler: parameter is modeled after the NSFileManager enumerate() function. If I include the @escaping you see there, I get the error "@escaping may only be applied to parameters of function type".<br class="">
>>><br class="">
>>> The second parameter, iterator:, seems to have no problems with @escaping.<br class="">
>>><br class="">
>>> func<br class="">
>>> iterate(directory inURL: URL?,<br class="">
>>> includingPropertiesForKeys: [URLResourceKey]? = nil,<br class="">
>>> options: FileManager.DirectoryEnumerationOptions = [],<br class="">
>>> errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,<br class="">
>>> iterator inIterator: (@escaping (URL) throws -> ())) rethrows<br class="">
>>> {<br class="">
>>> }<br class="">
>>><br class="">
>>> I'm not sure why I can't apply @escaping here. Can anyone enlighten me? Thank you.<br class="">
>>><br class="">
>>> --<br class="">
>>> Rick Mann<br class="">
>>> <a href="mailto:rmann@latencyzero.com" target="_blank" class="">rmann@latencyzero.com</a><br class="">
>>><br class="">
>>><br class="">
>>> _______________________________________________<br class="">
>>> swift-users mailing list<br class="">
>>> <a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a><br class="">
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class="">
>>> _______________________________________________<br class="">
>>> swift-users mailing list<br class="">
>>> <a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a><br class="">
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class="">
>><br class="">
><br class="">
><br class="">
> --<br class="">
> Rick Mann<br class="">
> <a href="mailto:rmann@latencyzero.com" target="_blank" class="">rmann@latencyzero.com</a><br class="">
><br class="">
><br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>