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

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:16 PM, Michael Ilseman via swift-users 
>  wrote:
> 
> 
>> On Sep 13, 2016, at 8:14 PM, Rick Mann  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.
> 

Definitely a bug in the AST printer

>> 
>>> On Sep 13, 2016, at 20:11 , Michael Ilseman  wrote:
>>> 
>>> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar 
>>> for Optional, 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 
  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  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 
  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
 
 
 ___
 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
>> rm...@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

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

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:37 PM, Shawn Erickson  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  > wrote:
> 
> > On Sep 13, 2016, at 8:14 PM, Rick Mann  > > 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  >> > wrote:
> >>
> >> TL;DR: The optional is already escaping, due to the fact that “T?" is 
> >> sugar for Optional, 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 
> >>> > 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  >>> > 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 

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

[Shawn Erickson via swift-users]

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  wrote:

>
> > On Sep 13, 2016, at 8:14 PM, Rick Mann  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  wrote:
> >>
> >> TL;DR: The optional is already escaping, due to the fact that “T?" is
> sugar for Optional, 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 
> 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
> >>> rm...@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
> > rm...@latencyzero.com
> >
> >
>
>

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

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:14 PM, Rick Mann  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  wrote:
>> 
>> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar 
>> for Optional, 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 
>>>  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  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 
>>>  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
>>> 
>>> 
>>> ___
>>> 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
> rm...@latencyzero.com
> 
> 

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

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

[Rick Mann via swift-users]

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?


> On Sep 13, 2016, at 20:11 , Michael Ilseman  wrote:
> 
> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar 
> for Optional, 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 
>>  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  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 
>>  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
>> 
>> 
>> ___
>> 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
rm...@latencyzero.com


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

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

[Michael Ilseman via swift-users]

TL;DR: The optional is already escaping, due to the fact that “T?" is sugar for 
Optional, 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 
>  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  > 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 
> > 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 
> 
> 
> ___
> 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

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

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

[Shawn Erickson via swift-users]

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  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
>> rm...@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

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

[Shawn Erickson via swift-users]

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
> rm...@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

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

[Rick Mann via swift-users]

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


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