Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Douglas Gregor via swift-evolution]

> On Dec 11, 2016, at 2:30 AM, Tommaso Piazza via swift-evolution 
>  wrote:
> 
> Hello Derrick,
> 
> I did not think of this as a bug but rather as an intentional limitation that 
> to me seems a little odd.
> 
> Yes, overloads 2,3 have at least ONE operand of type NonEmptyArray so when 
> declared as static function on NonEmptyArray they work fine. However Overload 
> 1 just mentions NonEmptyArray in the return type. I propose that it should 
> also be allowed as a static function on NonEmptyArray.

This was intentional:


https://github.com/apple/swift/commit/a15c485193c4dcb61c330be8c2d869758fff2c45

We believe that this restriction will help us provide more fine-grained 
dependency tracking in the compiler, which is important for minimizing the work 
to be performed in incremental builds. The general idea is that one can only 
find a particular operator when one has an argument of the type in which the 
operator is defined (or one of its subclasses or conforming types). I believe 
that we lose this fine-grained dependency if we allow the enclosing type to be 
mentioned (only) in the result type. So unless I’m wrong about one of those two 
things—either we don’t actually get the fine-grained dependency I’m expecting 
or we can still get it even if the enclosing type is only mentioned in the 
result type—I’m strongly against lifting this restriction. Incremental build 
times and fine-grained dependencies are extremely important for Swift compile 
times, and the language already has a way out by defining a global operator.

- Doug


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

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tommaso Piazza via swift-evolution]

Hi,
I just wanted to revive this discussion and understand if this is a welcome 
change or not.
Right now one can "fake" overload 1 inside NonEmptyArray by doing the following:
```
public struct NonEmptyArray {
    private var elements: Array
    private init(array: [Element]) {        self.elements = array    }
        public static func cons(lhs: Element, rhs: [Element]) -> 
NonEmptyArray {        return NonEmptyArray(array: rhs + 
[lhs])    }```
And "fake" the operator by calling the cons function
```//Overload 1public func •|(lhs: Element, rhs: [Element]) -> 
NonEmptyArray {    return NonEmptyArray.cons(array: rhs + [lhs])}```
While this is ok and gets the job done, it seems and artificial limitation (and 
a bit inconsistent) that only overloads mentioning the struct/class type in the 
operands are allowed.

I have updated my proposal to reflect this argument as well 
blender/swift-evolution
  
|  
|   
|   
|   ||

   |

  |
|  
||  
blender/swift-evolution
 swift-evolution - This maintains proposals for changes and user-visible 
enhancements to the Swift Programming La...  |   |

  |

  |

 



 

On Sunday, December 11, 2016 11:33 AM, Tommaso Piazza via swift-evolution 
 wrote:
 

 Hello Derrick,
I did not think of this as a bug but rather as an intentional limitation that 
to me seems a little odd.
Yes, overloads 2,3 have at least ONE operand of type NonEmptyArray so when 
declared as static function on NonEmptyArray they work fine. However Overload 1 
just mentions NonEmptyArray in the return type. I propose that it should also 
be allowed as a static function on NonEmptyArray.
As for the why it should be allowed my motivation is that all overloads that 
mention NonEmptyArray in their type signature should be allowed to be declared 
in the same namespace.Or one could argue that no overloads should be declarable 
inside NonEmptyArray. 
However this comes at a price.
Note that because overload 1 in the current situation must be left out of 
NonEmptyArray, the accessor modifier for properties and function in 
NonEmptyArray is fileprivate.With the change I propose this is no longer the 
case and the modifier is just private.
/Tommaso
On Sunday, December 11, 2016 5:49 AM, Derrick Ho  
wrote:
 

 I placed he code you wrote in the proposal in playgrounds and it works 
perfectly.  (reproduced below). Overloading operators used to only happen 
globally and since swift 3 they allowed you to put then inside the class/struct
public struct NonEmptyArray {

fileprivate var elements: Array

fileprivate init(array: [Element]) {
self.elements = array
}
}

//Overload 1
public func •|(lhs: Element, rhs: [Element]) -> NonEmptyArray 
{
return NonEmptyArray(array: rhs + [lhs])
}

//Overload 2
public func •|(lhs: Element, rhs:  NonEmptyArray) -> 
NonEmptyArray {
return NonEmptyArray(array: [lhs] + rhs.elements)
}

//Overload 3
public func •|(lhs: NonEmptyArray, rhs: 
NonEmptyArray) -> NonEmptyArray {
return NonEmptyArray(array: lhs.elements + rhs.elements)
}
However, as you have detailed when you place those overloads inside the 
struct/class, it does not work.  Actually I get an error that says that at 
least ONE of the arguments needs to be the same type.  In this case one of them 
needs to be NonEmptyArray. It is clearly not a bug, but rather a swift 
rule.
My recommendation is to just keep those overloads as global.  Is there a 
particular advantage to putting them inside the struct/class?



On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution 
 wrote:
Hello,
I have written a small proposal that would allow overloads of operators in 
structs/classes non only based on the types of the operands but on the return 
type as well.
Please let me know you thoughts,/Tommaso
https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md


That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not 
aware of the reasoning.

Actually, since the error message correctly parses the code, it probably is 
intentional… I don’t see the problem, myself, but I guess I’d have to know why 
it’s considered an error before judging whether I think we should remove the 
restriction.
- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution



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


   ___
swift-evolution mailing list

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tommaso Piazza via swift-evolution]

I cannot reply directly to this message 
https://www.mail-archive.com/swift-evolution@swift.org/msg19099.html so I will 
reply here instead.
I am suggesting that both behaviours should be allowed to co-exists (which is 
already the case, just there is this one exception.)
No matter the implications of access level I see this as a matter of 
consistency as well, at the end of the day an operator is a function with some 
sugar and a special name.
So while I am able to declare a static function as part of a struct/class like 
so:
```
public struct NonEmptyArray {
    private var elements: Array
    private init(array: [Element]) {        self.elements = array    }
        public static func cons(lhs: Element, rhs: [Element]) -> 
NonEmptyArray {        return NonEmptyArray(array: rhs + 
[lhs])    }```
And "fake" the operator by calling the cons function
```//Overload 1public func •|(lhs: Element, rhs: [Element]) -> 
NonEmptyArray {    return NonEmptyArray.cons(array: rhs + [lhs])}```
It seems to me that the only reason we're currently not allowed to declare the 
operator directly inside NonEmptyArray is because is begins with some special 
UTF8 character.
If you want to define your overload as free form functions or as static methods 
on structs/classes it's really up to you.
/Tommaso 

On Sunday, December 11, 2016 1:57 AM, Tommaso Piazza via swift-evolution 
 wrote:
 

 Hello,
I have written a small proposal that would allow overloads of operators in 
structs/classes non only based on the types of the operands but on the return 
type as well.
Please let me know you thoughts,/Tommaso
https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md



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


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

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tommaso Piazza via swift-evolution]

Thanks for the suggestion,
I have updated the proposal with the error and with the notes on `fileprivate` 
-> `private`
/Tommaso 

On Sunday, December 11, 2016 5:55 AM, Derrick Ho  
wrote:
 

 You may want to add the specific error to your proposal.  
error: member operator '•|' must have at least one argument of type 
'NonEmptyArray'        public static func •|(lhs: Element, 
rhs: [Element]) -> NonEmptyArray
On Sat, Dec 10, 2016 at 11:49 PM Derrick Ho  wrote:

I placed he code you wrote in the proposal in playgrounds and it works 
perfectly.  (reproduced below). Overloading operators used to only happen 
globally and since swift 3 they allowed you to put then inside the class/struct
public struct NonEmptyArray {

fileprivate var elements: Array

fileprivate init(array: [Element]) {
self.elements = array
}
}

//Overload 1
public func •|(lhs: Element, rhs: [Element]) -> NonEmptyArray 
{
return NonEmptyArray(array: rhs + [lhs])
}

//Overload 2
public func •|(lhs: Element, rhs:  NonEmptyArray) -> 
NonEmptyArray {
return NonEmptyArray(array: [lhs] + rhs.elements)
}

//Overload 3
public func •|(lhs: NonEmptyArray, rhs: 
NonEmptyArray) -> NonEmptyArray {
return NonEmptyArray(array: lhs.elements + rhs.elements)
}
However, as you have detailed when you place those overloads inside the 
struct/class, it does not work.  Actually I get an error that says that at 
least ONE of the arguments needs to be the same type.  In this case one of them 
needs to be NonEmptyArray. It is clearly not a bug, but rather a swift 
rule.
My recommendation is to just keep those overloads as global.  Is there a 
particular advantage to putting them inside the struct/class?



On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution 
 wrote:
Hello,
I have written a small proposal that would allow overloads of operators in 
structs/classes non only based on the types of the operands but on the return 
type as well.
Please let me know you thoughts,/Tommaso
https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md


That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not 
aware of the reasoning.

Actually, since the error message correctly parses the code, it probably is 
intentional… I don’t see the problem, myself, but I guess I’d have to know why 
it’s considered an error before judging whether I think we should remove the 
restriction.
- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution




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

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tino Heth via swift-evolution]

imho the current behaviour is fine.

I'll leave aside infix-operators, because with pre/postfix, the situation is 
simpler:
It seems slightly confusing to me to declare such an operator somewhere else 
but at the type it works on.

Afair the ability to declare an infix operator in a type definition came with 
the redefinition of access levels, possibly motivated by the ability to use 
private properties.
This might as well be the reason not to enforce that the operator has to be 
defined in the type of the first operand (which I'd consider to be preferable 
whenever possible).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Tommaso Piazza via swift-evolution]

Hello Derrick,
I did not think of this as a bug but rather as an intentional limitation that 
to me seems a little odd.
Yes, overloads 2,3 have at least ONE operand of type NonEmptyArray so when 
declared as static function on NonEmptyArray they work fine. However Overload 1 
just mentions NonEmptyArray in the return type. I propose that it should also 
be allowed as a static function on NonEmptyArray.
As for the why it should be allowed my motivation is that all overloads that 
mention NonEmptyArray in their type signature should be allowed to be declared 
in the same namespace.Or one could argue that no overloads should be declarable 
inside NonEmptyArray. 
However this comes at a price.
Note that because overload 1 in the current situation must be left out of 
NonEmptyArray, the accessor modifier for properties and function in 
NonEmptyArray is fileprivate.With the change I propose this is no longer the 
case and the modifier is just private.
/Tommaso
On Sunday, December 11, 2016 5:49 AM, Derrick Ho  
wrote:
 

 I placed he code you wrote in the proposal in playgrounds and it works 
perfectly.  (reproduced below). Overloading operators used to only happen 
globally and since swift 3 they allowed you to put then inside the class/struct
public struct NonEmptyArray {

fileprivate var elements: Array

fileprivate init(array: [Element]) {
self.elements = array
}
}

//Overload 1
public func •|(lhs: Element, rhs: [Element]) -> NonEmptyArray 
{
return NonEmptyArray(array: rhs + [lhs])
}

//Overload 2
public func •|(lhs: Element, rhs:  NonEmptyArray) -> 
NonEmptyArray {
return NonEmptyArray(array: [lhs] + rhs.elements)
}

//Overload 3
public func •|(lhs: NonEmptyArray, rhs: 
NonEmptyArray) -> NonEmptyArray {
return NonEmptyArray(array: lhs.elements + rhs.elements)
}
However, as you have detailed when you place those overloads inside the 
struct/class, it does not work.  Actually I get an error that says that at 
least ONE of the arguments needs to be the same type.  In this case one of them 
needs to be NonEmptyArray. It is clearly not a bug, but rather a swift 
rule.
My recommendation is to just keep those overloads as global.  Is there a 
particular advantage to putting them inside the struct/class?



On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution 
 wrote:


On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution 
 wrote:
Hello,
I have written a small proposal that would allow overloads of operators in 
structs/classes non only based on the types of the operands but on the return 
type as well.
Please let me know you thoughts,/Tommaso
https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md


That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not 
aware of the reasoning.

Actually, since the error message correctly parses the code, it probably is 
intentional… I don’t see the problem, myself, but I guess I’d have to know why 
it’s considered an error before judging whether I think we should remove the 
restriction.
- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution



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

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Derrick Ho via swift-evolution]

You may want to add the specific error to your proposal.

*error: member operator '•|' must have at least one argument of type
'NonEmptyArray'*

*public static func •|(lhs: Element, rhs: [Element]) ->
NonEmptyArray*

On Sat, Dec 10, 2016 at 11:49 PM Derrick Ho  wrote:

> I placed he code you wrote in the proposal in playgrounds and it works
> perfectly.  (reproduced below). Overloading operators used to only happen
> globally and since swift 3 they allowed you to put then inside the
> class/struct
>
> public struct NonEmptyArray {
>
> fileprivate var elements: Array
>
> fileprivate init(array: [Element]) {
> self.elements = array
> }
> }
>
> //Overload 1
> public func •|(lhs: Element, rhs: [Element]) -> 
> NonEmptyArray {
> return NonEmptyArray(array: rhs + [lhs])
> }
>
> //Overload 2
> public func •|(lhs: Element, rhs:  NonEmptyArray) -> 
> NonEmptyArray {
> return NonEmptyArray(array: [lhs] + rhs.elements)
> }
>
> //Overload 3
> public func •|(lhs: NonEmptyArray, rhs: 
> NonEmptyArray) -> NonEmptyArray {
> return NonEmptyArray(array: lhs.elements + rhs.elements)
> }
>
>
> However, as you have detailed when you place those overloads inside the
> struct/class, it does not work.  Actually I get an error that says that at
> least ONE of the arguments needs to be the same type.  In this case one of
> them needs to be NonEmptyArray. It is clearly not a bug, but
> rather a swift rule.
>
> My recommendation is to just keep those overloads as global.  Is there a
> particular advantage to putting them inside the struct/class?
>
>
>
> On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> I have written a small proposal that would allow overloads of operators in
> structs/classes non only based on the types of the operands but on the
> return type as well.
>
> Please let me know you thoughts,
> /Tommaso
>
>
> https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md
>
>
> That seems like a bug to me… Dunno, maybe it’s intentional and I’m just
> not aware of the reasoning.
>
>
> Actually, since the error message correctly parses the code, it probably
> *is* intentional… I don’t see the problem, myself, but I guess I’d have
> to know why it’s considered an error before judging whether I think we
> should remove the restriction.
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Derrick Ho via swift-evolution]

I placed he code you wrote in the proposal in playgrounds and it works
perfectly.  (reproduced below). Overloading operators used to only happen
globally and since swift 3 they allowed you to put then inside the
class/struct

public struct NonEmptyArray {

fileprivate var elements: Array

fileprivate init(array: [Element]) {
self.elements = array
}
}

//Overload 1
public func •|(lhs: Element, rhs: [Element]) ->
NonEmptyArray {
return NonEmptyArray(array: rhs + [lhs])
}

//Overload 2
public func •|(lhs: Element, rhs:  NonEmptyArray) ->
NonEmptyArray {
return NonEmptyArray(array: [lhs] + rhs.elements)
}

//Overload 3
public func •|(lhs: NonEmptyArray, rhs:
NonEmptyArray) -> NonEmptyArray {
return NonEmptyArray(array: lhs.elements + rhs.elements)
}


However, as you have detailed when you place those overloads inside the
struct/class, it does not work.  Actually I get an error that says that at
least ONE of the arguments needs to be the same type.  In this case one of
them needs to be NonEmptyArray. It is clearly not a bug, but
rather a swift rule.

My recommendation is to just keep those overloads as global.  Is there a
particular advantage to putting them inside the struct/class?



On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> I have written a small proposal that would allow overloads of operators in
> structs/classes non only based on the types of the operands but on the
> return type as well.
>
> Please let me know you thoughts,
> /Tommaso
>
>
> https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md
>
>
> That seems like a bug to me… Dunno, maybe it’s intentional and I’m just
> not aware of the reasoning.
>
>
> Actually, since the error message correctly parses the code, it probably
> *is* intentional… I don’t see the problem, myself, but I guess I’d have
> to know why it’s considered an error before judging whether I think we
> should remove the restriction.
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[Robert Widmann via swift-evolution]

I remember mentioning this in a meeting once.  The old behavior (post 
2.x-mid-operators-in-aggregates) did allow for this, the new one should too.

~Robert Widmann

2016/12/10 20:36、David Sweeris via swift-evolution  
のメッセージ:

> 
>>> On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> I have written a small proposal that would allow overloads of operators in 
>>> structs/classes non only based on the types of the operands but on the 
>>> return type as well.
>>> 
>>> Please let me know you thoughts,
>>> /Tommaso
>>> 
>>> https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md
>> 
>> That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not 
>> aware of the reasoning.
> 
> Actually, since the error message correctly parses the code, it probably is 
> intentional… I don’t see the problem, myself, but I guess I’d have to know 
> why it’s considered an error before judging whether I think we should remove 
> the restriction.
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[David Sweeris via swift-evolution]

> On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution 
>> > wrote:
>> 
>> Hello,
>> 
>> I have written a small proposal that would allow overloads of operators in 
>> structs/classes non only based on the types of the operands but on the 
>> return type as well.
>> 
>> Please let me know you thoughts,
>> /Tommaso
>> 
>> https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md
>>  
>> 
> 
> That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not 
> aware of the reasoning.

Actually, since the error message correctly parses the code, it probably is 
intentional… I don’t see the problem, myself, but I guess I’d have to know why 
it’s considered an error before judging whether I think we should remove the 
restriction.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

[David Sweeris via swift-evolution]

> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution 
>  wrote:
> 
> Hello,
> 
> I have written a small proposal that would allow overloads of operators in 
> structs/classes non only based on the types of the operands but on the return 
> type as well.
> 
> Please let me know you thoughts,
> /Tommaso
> 
> https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md
>  
> 

That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not 
aware of the reasoning.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution