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.
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> 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.
On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson <shawnce@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> 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.
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> wrote:
The following is the earlier thread I was talking about.
On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson <shawnce@gmail.com <mailto:shawnce@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.
handler is optional, but has @escaping. Is this an artifact of how Xcode presents system header files?
···
On Sep 13, 2016, at 20:11 , Michael Ilseman <milseman@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> 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@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> 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.
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 8:14 PM, Rick Mann <rmann@latencyzero.com> wrote:
On Sep 13, 2016, at 20:11 , Michael Ilseman <milseman@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> 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@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> 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.
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@apple.com> wrote:
> On Sep 13, 2016, at 8:14 PM, Rick Mann <rmann@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@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> 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@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> 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@latencyzero.com
>>>
>>>
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>
>
> --
> Rick Mann
> rmann@latencyzero.com
>
>
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.
Definitely a bug in the AST printer
···
On Sep 13, 2016, at 8:16 PM, Michael Ilseman via swift-users <swift-users@swift.org> wrote:
On Sep 13, 2016, at 8:14 PM, Rick Mann <rmann@latencyzero.com> wrote:
On Sep 13, 2016, at 20:11 , Michael Ilseman <milseman@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> 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@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> 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.
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.
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.
···
On Sep 13, 2016, at 8:37 PM, Shawn Erickson <shawnce@gmail.com> wrote:
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@apple.com <mailto:milseman@apple.com>> wrote:
> On Sep 13, 2016, at 8:14 PM, Rick Mann <rmann@latencyzero.com <mailto:rmann@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@apple.com <mailto:milseman@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 <shawnce@gmail.com <mailto:shawnce@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
>>> rmann@latencyzero.com <mailto:rmann@latencyzero.com>
>>>
>>>
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> 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
>>
>
>
> --
> Rick Mann
> rmann@latencyzero.com <mailto:rmann@latencyzero.com>
>
>