> 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