[swift-users] @escaping may only be applied to parameters of function type

[Shawn Erickson]

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. 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 <milseman at apple.com> wrote:

>
> > On Sep 13, 2016, at 8:14 PM, Rick Mann <rmann at 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 <milseman at 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 at 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 <shawnce at 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 at 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
> >>> rmann at latencyzero.com
> >>>
> >>>
> >>> _______________________________________________
> >>> swift-users mailing list
> >>> swift-users at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-users
> >>> _______________________________________________
> >>> swift-users mailing list
> >>> swift-users at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-users
> >>
> >
> >
> > --
> > Rick Mann
> > rmann at latencyzero.com
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160914/14538186/attachment.html>