@escaping may only be applied to parameters of function type


(Rick M) #1

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


(Shawn Erickson) #2

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


(Shawn Erickson) #3

The following is the earlier thread I was talking about.

[swift-users] Swift 3 (Xcode 8 GM) issue with @escaping
<https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003179.html>

-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


(Michael Ilseman) #4

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 <https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003179.html>

-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
https://lists.swift.org/mailman/listinfo/swift-users


(Rick M) #5

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


(Michael Ilseman) #6

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

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


(Shawn Erickson) #7

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


(Michael Ilseman) #8

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

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

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


(Michael Ilseman) #9

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.

···

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