<div dir="ltr">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><br></div><div>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. 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><br></div><div>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><br></div><div>-Shawn</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 13, 2016 at 8:16 PM Michael Ilseman <<a href="mailto:milseman@apple.com">milseman@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Sep 13, 2016, at 8:14 PM, Rick Mann <<a href="mailto:rmann@latencyzero.com" target="_blank">rmann@latencyzero.com</a>> wrote:<br>
><br>
> But the Apple declaration (accessible via Xcode) of the method it's based on looks like this:<br>
><br>
> open func enumerator(at url: URL,<br>
> includingPropertiesForKeys keys: [URLResourceKey]?,<br>
> options mask: FileManager.DirectoryEnumerationOptions = [],<br>
> errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)<br>
> -> FileManager.DirectoryEnumerator?<br>
><br>
> handler is optional, but has @escaping. Is this an artifact of how Xcode presents system header files?<br>
><br>
<br>
That’s certainly funky. Might be that or a bug in the AST printer.<br>
<br>
><br>
>> On Sep 13, 2016, at 20:11 , Michael Ilseman <<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>> wrote:<br>
>><br>
>> 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>
>><br>
>> 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>
>><br>
>>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:<br>
>>><br>
>>> The following is the earlier thread I was talking about.<br>
>>><br>
>>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping<br>
>>><br>
>>> -Shawn<br>
>>><br>
>>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson <<a href="mailto:shawnce@gmail.com" target="_blank">shawnce@gmail.com</a>> wrote:<br>
>>> 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>
>>><br>
>>> 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>
>>><br>
>>> -Shawn<br>
>>> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:<br>
>>> 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>
>>><br>
>>> The second parameter, iterator:, seems to have no problems with @escaping.<br>
>>><br>
>>> func<br>
>>> iterate(directory inURL: URL?,<br>
>>> includingPropertiesForKeys: [URLResourceKey]? = nil,<br>
>>> options: FileManager.DirectoryEnumerationOptions = [],<br>
>>> errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,<br>
>>> iterator inIterator: (@escaping (URL) throws -> ())) rethrows<br>
>>> {<br>
>>> }<br>
>>><br>
>>> I'm not sure why I can't apply @escaping here. Can anyone enlighten me? Thank you.<br>
>>><br>
>>> --<br>
>>> Rick Mann<br>
>>> <a href="mailto:rmann@latencyzero.com" target="_blank">rmann@latencyzero.com</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> swift-users mailing list<br>
>>> <a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br>
>>> _______________________________________________<br>
>>> swift-users mailing list<br>
>>> <a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br>
>><br>
><br>
><br>
> --<br>
> Rick Mann<br>
> <a href="mailto:rmann@latencyzero.com" target="_blank">rmann@latencyzero.com</a><br>
><br>
><br>
<br>
</blockquote></div>