> On Sep 13, 2016, at 8:37 PM, Shawn Erickson <shaw...@gmail.com> wrote:
> 
> 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).
> 
> 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.

Link for those following along at home: 
https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md

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.

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).

I would be in favor (and can help you champion) an escaping rule that 
propagates through generic parameters and non-nominal-type members. 

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

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to