Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Matthew Johnson via swift-evolution]

> On Jan 10, 2018, at 2:19 PM, Rex Fenley  wrote:
> 
> Have you found anyone else to help on this one? I would like to dive in 
> myself but I don't have any experience with the compiler and not sure about 
> the size of the workload here.

Hi Rex, thank you for offering to help!  I have not found anyone else to help 
out on implementation but am still extremely interested in seeing this happen 
and willing to help out by drafting the proposal, etc.

Is anyone who is familiar with it able to give Rex an idea of scope and / or 
willing to help Rex get up to speed?

> 
> On Tue, Dec 5, 2017 at 3:34 PM, Rex Fenley  > wrote:
> Huge +1, I've asked for this in the past too.
> 
> Have you also found this limitation frustrating? 
>   - Yes
> 
> In what contexts?
>   - APIs that have this requirement and end up enforcing them through runtime 
> type checking and throws. Shows up in some network data mapping code I have 
> that generalizes over Core Data and Realm (and other databases). The protocol 
> implementer must specify the subtype for the raw mapping of JSON and base 
> type for the DB reading/writing layer. Could see this showing up whenever 
> there's a separation of concerns between what business logic belongs to the 
> base type and subtypes of a more generalized system. I could potentially see 
> the same issue showing up in code generalizing the mapping of data to UI, 
> like UITableView/UITableViewCell.
> 
> Does anyone have reservations about introducing this capability?
>   - I do not
>> One of the most frequent frustrations I encounter when writing generic code 
>> in Swift is the requirement that supertype constraints be concrete.  When I 
>> mentioned this on Twitter 
>> (https://twitter.com/anandabits/status/929958479598534656 
>> ) Doug Gregor 
>> mentioned that this feature is smaller and mostly straightforward to design 
>> and implement (https://twitter.com/dgregor79/status/929975472779288576 
>> ).
>> 
>> I currently have a PR open to add the high-level description of this feature 
>> found below to the generics manifesto 
>> (https://github.com/apple/swift/pull/13012 
>> ):
>> 
>> Currently, supertype constraints may only be specified using a concrete 
>> class or protocol type.  This prevents us from abstracting over the 
>> supertype.
>> 
>> ```swift
>> protocol P {
>>   associatedtype Base
>>   associatedtype Derived: Base
>> }
>> ```
>> 
>> In the above example `Base` may be any type.  `Derived` may be the same as 
>> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
>> supported by Swift should be supported in this context including, but not 
>> limited to, classes and subclasses, existentials and conforming concrete 
>> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
>> `((Derived) -> Void)`, etc.
>> 
>> Generalized supertype constraints would be accepted in all syntactic 
>> locations where generic constraints are accepted.
>> 
>> I would like to see generalized supertype constraints make it into Swift 5 
>> if possible.  I am not an implementer so I will not be able to bring a 
>> proposal forward alone but am interested in collaborating with anyone 
>> interested in working on implementation.
>> 
>> I am also interested in hearing general feedback on this feature from the 
>> community at large.  Have you also found this limitation frustrating?  In 
>> what contexts?  Does anyone have reservations about introducing this 
>> capability?  If so, what are they?
>> 
>> Matthew
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Rex Fenley via swift-evolution]

Have you found anyone else to help on this one? I would like to dive in
myself but I don't have any experience with the compiler and not sure about
the size of the workload here.

On Tue, Dec 5, 2017 at 3:34 PM, Rex Fenley  wrote:

> Huge +1, I've asked for this in the past too.
>
> Have you also found this limitation frustrating?
>   - Yes
>
> In what contexts?
>   - APIs that have this requirement and end up enforcing them through
> runtime type checking and throws. Shows up in some network data mapping
> code I have that generalizes over Core Data and Realm (and other
> databases). The protocol implementer must specify the subtype for the raw
> mapping of JSON and base type for the DB reading/writing layer. Could see
> this showing up whenever there's a separation of concerns between what
> business logic belongs to the base type and subtypes of a more generalized
> system. I could potentially see the same issue showing up in code
> generalizing the mapping of data to UI, like UITableView/UITableViewCell.
>
> Does anyone have reservations about introducing this capability?
>   - I do not
>
> One of the most frequent frustrations I encounter when writing generic
> code in Swift is the requirement that supertype constraints be concrete.
> When I mentioned this on Twitter (https://twitter.com/anandabit
> s/status/929958479598534656) Doug Gregor mentioned that this feature is
> smaller and mostly straightforward to design and implement (
> https://twitter.com/dgregor79/status/929975472779288576).
>
> I currently have a PR open to add the high-level description of this
> feature found below to the generics manifesto (
> https://github.com/apple/swift/pull/13012):
>
> Currently, supertype constraints may only be specified using a concrete
> class or protocol type.  This prevents us from abstracting over the
> supertype.
>
> ```swift
> protocol P {
>   associatedtype Base
>   associatedtype Derived: Base
> }
> ```
>
> In the above example `Base` may be any type.  `Derived` may be the same as
> `Base` or may be _any_ subtype of `Base`.  All subtype relationships
> supported by Swift should be supported in this context including, but not
> limited to, classes and subclasses, existentials and conforming concrete
> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and
> `((Derived) -> Void)`, etc.
>
> Generalized supertype constraints would be accepted in all syntactic
> locations where generic constraints are accepted.
>
> I would like to see generalized supertype constraints make it into Swift 5
> if possible.  I am not an implementer so I will not be able to bring a
> proposal forward alone but am interested in collaborating with anyone
> interested in working on implementation.
>
> I am also interested in hearing general feedback on this feature from the
> community at large.  Have you also found this limitation frustrating?  In
> what contexts?  Does anyone have reservations about introducing this
> capability?  If so, what are they?
>
> Matthew
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
>
> Rex Fenley  |  IOS DEVELOPER
>
> Remind.com  |  BLOG   |
>  FOLLOW US   |  LIKE US
> 
>



-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

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

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Magnus Ahltorp via swift-evolution]

Mutation is more or less modeled as reassignment in Swift, there is no 
difference between a variable that can be mutated and one that can be 
reassigned (right?). There are however differences between inout's real 
behaviour and what some might expect; some might expect that it is modified at 
the same time (and as many times) as if the function was inlined.

struct F {
var a : Int {
didSet {
print("set \(a)")
}
}
}

func setTimes(a: inout Int, times: Int) {
for _ in 1...times {
a += 1
}
}

var foo = F(a: 0)

// prints set 1 … set 10
for _ in 1...10 {
foo.a += 1
}

setTimes(a: , times: 10) // only prints set 20


However, your generalization is already possible, just change the function head 
to:

func foo(_ p: inout E)

which, if we add a member to the protocol and something meaningful for the 
function to do becomes something like this:

protocol P { var a : Int {get set} }

func foo(_ p: inout E) {
p.a += 1
}

struct F : P { var a : Int }

var f = F(a: 0)

foo()
print(f)

Was there some other problem you were trying to solve that can't be solved by 
doing this?

/Magnus

> 11 Dec. 2017 03:49 Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I see, that makes totally sense. I thought about `inout` only in terms of 
> mutation not reassignment from within the scope itself.
> 
> 
> Am 10. Dezember 2017 um 17:56:56, Jonathan Keller (jkeller...@icloud.com) 
> schrieb:
> 
>> No, inout should *not* be covariant, since foo can assign any subtype of P 
>> to its parameter, not just F:
>> 
>> protocol P {}
>> struct F: P {}
>> struct G: P {}
>> 
>> func foo(_ p: inout P) {
>> p = G()
>> }
>> 
>> var f = F()
>> foo() // assigns a value of type G to a variable of type F
>> 
>> From Jonathan
>> 
>> On Dec 10, 2017, at 12:51 AM, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>>> Hello Matthew, I have more more question about the generalized supertype 
>>> constraints. Does the generalization also covers inout? I found a really 
>>> annoying case with inout.
>>> 
>>> protocol P {}
>>> 
>>> func foo(_ p: inout P) {
>>> print(p)
>>> }
>>> 
>>> struct F : P {}
>>> 
>>> var f = F()
>>> 
>>> foo() // won't compile until we explicitly write `var f: P = F()`
>>> 
>>> Shouldn’t we allow inout to have subtypes as well, like inout F : inout P?
>>> 
>>> This is actually one of the pain points with the generic version of the 
>>> print function. We cannot pass an arbitrary TextOutputStream to it without 
>>> sacrificing the type. I doubt the generic print function is justified, 
>>> because TextOuputStream does not have associated types nor a Self 
>>> constraint. Furthermore it forces you to create a custom type-erased 
>>> wrapper that can hold an arbitrary TextOutputSteram.
>>> 
>>> If this is part of a totally different topic, I’ll move it in it’s own 
>>> thread.
>>> 
>>> 
>>> 
>>> Am 2. Dezember 2017 um 19:03:24, Matthew Johnson via swift-evolution 
>>> (swift-evolution@swift.org) schrieb:
>>> 
 This thread received very light, but positive feedback.  I would really 
 like to see this feature added and am willing to draft and official 
 proposal but am not able to implement it.  If anyone is interested in 
 collaborating just let me know.
 
 
> On Nov 24, 2017, at 5:03 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> One of the most frequent frustrations I encounter when writing generic 
> code in Swift is the requirement that supertype constraints be concrete.  
> When I mentioned this on Twitter 
> (https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
> mentioned that this feature is smaller and mostly straightforward to 
> design and implement 
> (https://twitter.com/dgregor79/status/929975472779288576).
> 
> I currently have a PR open to add the high-level description of this 
> feature found below to the generics manifesto 
> (https://github.com/apple/swift/pull/13012):
> 
> Currently, supertype constraints may only be specified using a concrete 
> class or protocol type.  This prevents us from abstracting over the 
> supertype.
> 
> ```swift
> protocol P {
>   associatedtype Base
>   associatedtype Derived: Base
> }
> ```
> 
> In the above example `Base` may be any type.  `Derived` may be the same 
> as `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
> supported by Swift should be supported in this context including, but not 
> limited to, classes and subclasses, existentials and conforming concrete 
> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
> `((Derived) -> Void)`, etc.
> 
> Generalized supertype constraints would be accepted in all syntactic 
> locations where generic constraints are accepted.
> 
> I would like to see 

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Adrian Zubarev via swift-evolution]

I see, that makes totally sense. I thought about `inout` only in terms of 
mutation not reassignment from within the scope itself.


Am 10. Dezember 2017 um 17:56:56, Jonathan Keller (jkeller...@icloud.com) 
schrieb:

No, inout should *not* be covariant, since foo can assign any subtype of P to 
its parameter, not just F:

protocol P {}
struct F: P {}
struct G: P {}

func foo(_ p: inout P) {
    p = G()
}

var f = F()
foo() // assigns a value of type G to a variable of type F

>From Jonathan

On Dec 10, 2017, at 12:51 AM, Adrian Zubarev via swift-evolution 
 wrote:

Hello Matthew, I have more more question about the generalized supertype 
constraints. Does the generalization also covers inout? I found a really 
annoying case with inout.

protocol P {}

func foo(_ p: inout P) {
print(p)
}

struct F : P {}

var f = F()

foo() // won't compile until we explicitly write `var f: P = F()`
Shouldn’t we allow inout to have subtypes as well, like inout F : inout P?

This is actually one of the pain points with the generic version of the print 
function. We cannot pass an arbitrary TextOutputStream to it without 
sacrificing the type. I doubt the generic print function is justified, because 
TextOuputStream does not have associated types nor a Self constraint. 
Furthermore it forces you to create a custom type-erased wrapper that can hold 
an arbitrary TextOutputSteram.

If this is part of a totally different topic, I’ll move it in it’s own thread.



Am 2. Dezember 2017 um 19:03:24, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:

This thread received very light, but positive feedback.  I would really like to 
see this feature added and am willing to draft and official proposal but am not 
able to implement it.  If anyone is interested in collaborating just let me 
know.


On Nov 24, 2017, at 5:03 PM, Matthew Johnson via swift-evolution 
 wrote:

One of the most frequent frustrations I encounter when writing generic code in 
Swift is the requirement that supertype constraints be concrete.  When I 
mentioned this on Twitter 
(https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
mentioned that this feature is smaller and mostly straightforward to design and 
implement (https://twitter.com/dgregor79/status/929975472779288576).

I currently have a PR open to add the high-level description of this feature 
found below to the generics manifesto 
(https://github.com/apple/swift/pull/13012):

Currently, supertype constraints may only be specified using a concrete class 
or protocol type.  This prevents us from abstracting over the supertype.

```swift
protocol P {
  associatedtype Base
  associatedtype Derived: Base
}
```

In the above example `Base` may be any type.  `Derived` may be the same as 
`Base` or may be _any_ subtype of `Base`.  All subtype relationships supported 
by Swift should be supported in this context including, but not limited to, 
classes and subclasses, existentials and conforming concrete types or refining 
existentials, `T?` and  `T`, `((Base) -> Void)` and `((Derived) -> Void)`, etc.

Generalized supertype constraints would be accepted in all syntactic locations 
where generic constraints are accepted.

I would like to see generalized supertype constraints make it into Swift 5 if 
possible.  I am not an implementer so I will not be able to bring a proposal 
forward alone but am interested in collaborating with anyone interested in 
working on implementation.

I am also interested in hearing general feedback on this feature from the 
community at large.  Have you also found this limitation frustrating?  In what 
contexts?  Does anyone have reservations about introducing this capability?  If 
so, what are they?

Matthew

___
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
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] [Pitch] Generalized supertype constraints

[Jonathan Keller via swift-evolution]

No, inout should *not* be covariant, since foo can assign any subtype of P to 
its parameter, not just F:

protocol P {}
struct F: P {}
struct G: P {}

func foo(_ p: inout P) {
p = G()
}

var f = F()
foo() // assigns a value of type G to a variable of type F

>From Jonathan

> On Dec 10, 2017, at 12:51 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Hello Matthew, I have more more question about the generalized supertype 
> constraints. Does the generalization also covers inout? I found a really 
> annoying case with inout.
> 
> protocol P {}
> 
> func foo(_ p: inout P) {
> print(p)
> }
> 
> struct F : P {}
> 
> var f = F()
> 
> foo() // won't compile until we explicitly write `var f: P = F()`
> Shouldn’t we allow inout to have subtypes as well, like inout F : inout P?
> 
> This is actually one of the pain points with the generic version of the print 
> function. We cannot pass an arbitrary TextOutputStream to it without 
> sacrificing the type. I doubt the generic print function is justified, 
> because TextOuputStream does not have associated types nor a Self constraint. 
> Furthermore it forces you to create a custom type-erased wrapper that can 
> hold an arbitrary TextOutputSteram.
> 
> If this is part of a totally different topic, I’ll move it in it’s own thread.
> 
> 
> 
> Am 2. Dezember 2017 um 19:03:24, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> This thread received very light, but positive feedback.  I would really like 
>> to see this feature added and am willing to draft and official proposal but 
>> am not able to implement it.  If anyone is interested in collaborating just 
>> let me know.
>> 
>> 
>>> On Nov 24, 2017, at 5:03 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> One of the most frequent frustrations I encounter when writing generic code 
>>> in Swift is the requirement that supertype constraints be concrete.  When I 
>>> mentioned this on Twitter 
>>> (https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
>>> mentioned that this feature is smaller and mostly straightforward to design 
>>> and implement (https://twitter.com/dgregor79/status/929975472779288576).
>>> 
>>> I currently have a PR open to add the high-level description of this 
>>> feature found below to the generics manifesto 
>>> (https://github.com/apple/swift/pull/13012):
>>> 
>>> Currently, supertype constraints may only be specified using a concrete 
>>> class or protocol type.  This prevents us from abstracting over the 
>>> supertype.
>>> 
>>> ```swift
>>> protocol P {
>>>   associatedtype Base
>>>   associatedtype Derived: Base
>>> }
>>> ```
>>> 
>>> In the above example `Base` may be any type.  `Derived` may be the same as 
>>> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
>>> supported by Swift should be supported in this context including, but not 
>>> limited to, classes and subclasses, existentials and conforming concrete 
>>> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
>>> `((Derived) -> Void)`, etc.
>>> 
>>> Generalized supertype constraints would be accepted in all syntactic 
>>> locations where generic constraints are accepted.
>>> 
>>> I would like to see generalized supertype constraints make it into Swift 5 
>>> if possible.  I am not an implementer so I will not be able to bring a 
>>> proposal forward alone but am interested in collaborating with anyone 
>>> interested in working on implementation.
>>> 
>>> I am also interested in hearing general feedback on this feature from the 
>>> community at large.  Have you also found this limitation frustrating?  In 
>>> what contexts?  Does anyone have reservations about introducing this 
>>> capability?  If so, what are they?
>>> 
>>> Matthew
>>> 
>>> ___
>>> 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
> 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] [Pitch] Generalized supertype constraints

[Adrian Zubarev via swift-evolution]

Hello Matthew, I have more more question about the generalized supertype 
constraints. Does the generalization also covers inout? I found a really 
annoying case with inout.

protocol P {}

func foo(_ p: inout P) {
print(p)
}

struct F : P {}

var f = F()

foo() // won't compile until we explicitly write `var f: P = F()`
Shouldn’t we allow inout to have subtypes as well, like inout F : inout P?

This is actually one of the pain points with the generic version of the print 
function. We cannot pass an arbitrary TextOutputStream to it without 
sacrificing the type. I doubt the generic print function is justified, because 
TextOuputStream does not have associated types nor a Self constraint. 
Furthermore it forces you to create a custom type-erased wrapper that can hold 
an arbitrary TextOutputSteram.

If this is part of a totally different topic, I’ll move it in it’s own thread.



Am 2. Dezember 2017 um 19:03:24, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:

This thread received very light, but positive feedback.  I would really like to 
see this feature added and am willing to draft and official proposal but am not 
able to implement it.  If anyone is interested in collaborating just let me 
know.


On Nov 24, 2017, at 5:03 PM, Matthew Johnson via swift-evolution 
 wrote:

One of the most frequent frustrations I encounter when writing generic code in 
Swift is the requirement that supertype constraints be concrete.  When I 
mentioned this on Twitter 
(https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
mentioned that this feature is smaller and mostly straightforward to design and 
implement (https://twitter.com/dgregor79/status/929975472779288576).

I currently have a PR open to add the high-level description of this feature 
found below to the generics manifesto 
(https://github.com/apple/swift/pull/13012):

Currently, supertype constraints may only be specified using a concrete class 
or protocol type.  This prevents us from abstracting over the supertype.

```swift
protocol P {
  associatedtype Base
  associatedtype Derived: Base
}
```

In the above example `Base` may be any type.  `Derived` may be the same as 
`Base` or may be _any_ subtype of `Base`.  All subtype relationships supported 
by Swift should be supported in this context including, but not limited to, 
classes and subclasses, existentials and conforming concrete types or refining 
existentials, `T?` and  `T`, `((Base) -> Void)` and `((Derived) -> Void)`, etc.

Generalized supertype constraints would be accepted in all syntactic locations 
where generic constraints are accepted.

I would like to see generalized supertype constraints make it into Swift 5 if 
possible.  I am not an implementer so I will not be able to bring a proposal 
forward alone but am interested in collaborating with anyone interested in 
working on implementation.

I am also interested in hearing general feedback on this feature from the 
community at large.  Have you also found this limitation frustrating?  In what 
contexts?  Does anyone have reservations about introducing this capability?  If 
so, what are they?

Matthew

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

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[David James via swift-evolution]

+1

It would be nice to have generic supertype constraints, with syntax along the 
lines of `where A:B`. 

Not sure if this is the same as what’s being suggested.

Example:
struct ViewWrapper {
let views:[T]
func add(_ view:V) -> ViewWrapper where V:T { // V must be a 
subtype of T
let newViews = views + [view] // pseudo code
return ViewWrapper(views: newViews)
}
}
let controls  = ViewWrapper(views:[])
controls.add(UIButton()) // succeeds, UIButton is a UIControl
controls.add(UIView()) // fails, UIView is not a UIControl
David

> On 6 Dec 2017, at 00:34, Rex Fenley via swift-evolution 
>  wrote:
> 
> Huge +1, I've asked for this in the past too.
> 
> Have you also found this limitation frustrating? 
>   - Yes
> 
> In what contexts?
>   - APIs that have this requirement and end up enforcing them through runtime 
> type checking and throws. Shows up in some network data mapping code I have 
> that generalizes over Core Data and Realm (and other databases). The protocol 
> implementer must specify the subtype for the raw mapping of JSON and base 
> type for the DB reading/writing layer. Could see this showing up whenever 
> there's a separation of concerns between what business logic belongs to the 
> base type and subtypes of a more generalized system. I could potentially see 
> the same issue showing up in code generalizing the mapping of data to UI, 
> like UITableView/UITableViewCell.
> 
> Does anyone have reservations about introducing this capability?
>   - I do not
>> One of the most frequent frustrations I encounter when writing generic code 
>> in Swift is the requirement that supertype constraints be concrete.  When I 
>> mentioned this on Twitter 
>> (https://twitter.com/anandabits/status/929958479598534656 
>> ) Doug Gregor 
>> mentioned that this feature is smaller and mostly straightforward to design 
>> and implement (https://twitter.com/dgregor79/status/929975472779288576 
>> ).
>> 
>> I currently have a PR open to add the high-level description of this feature 
>> found below to the generics manifesto 
>> (https://github.com/apple/swift/pull/13012 
>> ):
>> 
>> Currently, supertype constraints may only be specified using a concrete 
>> class or protocol type.  This prevents us from abstracting over the 
>> supertype.
>> 
>> ```swift
>> protocol P {
>>   associatedtype Base
>>   associatedtype Derived: Base
>> }
>> ```
>> 
>> In the above example `Base` may be any type.  `Derived` may be the same as 
>> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
>> supported by Swift should be supported in this context including, but not 
>> limited to, classes and subclasses, existentials and conforming concrete 
>> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
>> `((Derived) -> Void)`, etc.
>> 
>> Generalized supertype constraints would be accepted in all syntactic 
>> locations where generic constraints are accepted.
>> 
>> I would like to see generalized supertype constraints make it into Swift 5 
>> if possible.  I am not an implementer so I will not be able to bring a 
>> proposal forward alone but am interested in collaborating with anyone 
>> interested in working on implementation.
>> 
>> I am also interested in hearing general feedback on this feature from the 
>> community at large.  Have you also found this limitation frustrating?  In 
>> what contexts?  Does anyone have reservations about introducing this 
>> capability?  If so, what are they?
>> 
>> Matthew
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

David James

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

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Matthew Johnson via swift-evolution]

This thread received very light, but positive feedback.  I would really like to 
see this feature added and am willing to draft and official proposal but am not 
able to implement it.  If anyone is interested in collaborating just let me 
know.


> On Nov 24, 2017, at 5:03 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> One of the most frequent frustrations I encounter when writing generic code 
> in Swift is the requirement that supertype constraints be concrete.  When I 
> mentioned this on Twitter 
> (https://twitter.com/anandabits/status/929958479598534656 
> ) Doug Gregor 
> mentioned that this feature is smaller and mostly straightforward to design 
> and implement (https://twitter.com/dgregor79/status/929975472779288576 
> ).
> 
> I currently have a PR open to add the high-level description of this feature 
> found below to the generics manifesto 
> (https://github.com/apple/swift/pull/13012 
> ):
> 
> Currently, supertype constraints may only be specified using a concrete class 
> or protocol type.  This prevents us from abstracting over the supertype.
> 
> ```swift
> protocol P {
>   associatedtype Base
>   associatedtype Derived: Base
> }
> ```
> 
> In the above example `Base` may be any type.  `Derived` may be the same as 
> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
> supported by Swift should be supported in this context including, but not 
> limited to, classes and subclasses, existentials and conforming concrete 
> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
> `((Derived) -> Void)`, etc.
> 
> Generalized supertype constraints would be accepted in all syntactic 
> locations where generic constraints are accepted.
> 
> I would like to see generalized supertype constraints make it into Swift 5 if 
> possible.  I am not an implementer so I will not be able to bring a proposal 
> forward alone but am interested in collaborating with anyone interested in 
> working on implementation.
> 
> I am also interested in hearing general feedback on this feature from the 
> community at large.  Have you also found this limitation frustrating?  In 
> what contexts?  Does anyone have reservations about introducing this 
> capability?  If so, what are they?
> 
> Matthew
> 
> ___
> 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] [Pitch] Generalized supertype constraints

[Karl Wagner via swift-evolution]

I think this is essential for creating good, general-purpose abstractions with 
Swift.

For example, currently I have a protocol which models a CRUD database. There is 
some ORM behaviour which translates the DB information in to model objects, but 
of course, each database might have different requirements. Currently ORMs use 
class hierarchies to give you that behaviour - e.g. CoreData has 
NSManagedObject, Realm has its own “Object” class, etc. This requires that I 
write separate protocols for each base-type, like this:

protocol RealmObjectStore {
func create(_ objects: S) where S: Sequence, S.Element: RealmSwift.Object
func read(_ command: FetchCommand) -> [T] where T: RealmSwift.Object
// …etc
}

Ideally, my my protocol would look something like this:

protocol ObjectStore {
associatedtype Storable // might be a concrete type; might be a protocol.

func create(_ objects: S) where S: Sequence, S.Element: Self.Storable
func read(_ command: FetchCommand) -> [T] where T: Self.Storable
// …etc
}

That would allow me to abstract over CoreData and Realm using a single 
protocol, as far as they are both able to act like CRUD databases:

class CoreDataStore: ObjectStore {
typealias Storable = NSManagedObject
   // …etc
}

class RealmDataStore: ObjectStore {
typealias Storable = RealmObject
   // …etc
}

Okay, so technically I could do that today by requiring that Storable is a 
subclass of NSObject. But doing this would also us to move beyond class 
hierarchies - what does an ObjectStore really need to store and retrieve its 
data? Well, that depends on the store. Maybe some will require all of the 
dynamism and reflection of Objective-C, and so will continue to require 
subclassing, but maybe for some it will be enough to have Codable conformance 
and a primary key. You could satisfy that with a value-type:

protocol ValueDBStorable: Codable {
var primaryKey: KeyPath { get }
}

class ValueDBStore: ObjectStore {
typealias Storable = ValueDBStorable
// …etc
} 

So I think it’s a very powerful feature and would love to use it. However, I do 
think it would underscore the need for nested protocols.

- Karl


> On 25. Nov 2017, at 00:03, Matthew Johnson via swift-evolution 
>  wrote:
> 
> One of the most frequent frustrations I encounter when writing generic code 
> in Swift is the requirement that supertype constraints be concrete.  When I 
> mentioned this on Twitter 
> (https://twitter.com/anandabits/status/929958479598534656 
> ) Doug Gregor 
> mentioned that this feature is smaller and mostly straightforward to design 
> and implement (https://twitter.com/dgregor79/status/929975472779288576 
> ).
> 
> I currently have a PR open to add the high-level description of this feature 
> found below to the generics manifesto 
> (https://github.com/apple/swift/pull/13012 
> ):
> 
> Currently, supertype constraints may only be specified using a concrete class 
> or protocol type.  This prevents us from abstracting over the supertype.
> 
> ```swift
> protocol P {
>   associatedtype Base
>   associatedtype Derived: Base
> }
> ```
> 
> In the above example `Base` may be any type.  `Derived` may be the same as 
> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
> supported by Swift should be supported in this context including, but not 
> limited to, classes and subclasses, existentials and conforming concrete 
> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
> `((Derived) -> Void)`, etc.
> 
> Generalized supertype constraints would be accepted in all syntactic 
> locations where generic constraints are accepted.
> 
> I would like to see generalized supertype constraints make it into Swift 5 if 
> possible.  I am not an implementer so I will not be able to bring a proposal 
> forward alone but am interested in collaborating with anyone interested in 
> working on implementation.
> 
> I am also interested in hearing general feedback on this feature from the 
> community at large.  Have you also found this limitation frustrating?  In 
> what contexts?  Does anyone have reservations about introducing this 
> capability?  If so, what are they?
> 
> Matthew
> 
> ___
> 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] [Pitch] Generalized supertype constraints

[Dennis Weissmann via swift-evolution]

You’re right, I misunderstood that paragraph (maybe I read what I wanted to 
read :D). Thank you very much for the clarification and I’ll take a closer look 
at your proposal tomorrow!

- Dennis

Sent from my iPhone

> On 25. Nov 2017, at 10:37 PM, Adrian Zubarev 
>  wrote:
> 
> Well no, this proposal won’t allow your example. The problem in your example 
> actually has different roots - *Metatypes*. As by today, meta types are 
> somehow broken, especially in generic / associated type context. Furthermore 
> there is currently no way to express that you may want a subtype for an 
> existential metatype instead of the static metatype.
> 
> For more informations about meta types and who some of us would like them to 
> work, read our proposal here:
> https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md
> 
> Then your example could be expressed as:
> 
> ```
> func register(_ service: Service, ofType type: Type) where AnyType : 
> AnyType {}
> 
> // or if I’m not mistaken we can make use if implicit existential like this 
> then
> func register(_ service: Service, ofType type: Type) where S : Service 
> {}
> ```
> 
> I don't want to dive any deeper about the metatype pain points, because I 
> don’t want to prevent the success of the pitched idea with an off-topic.
> 
> 
> Am 25. November 2017 um 16:34:58, Dennis Weissmann 
> (den...@dennisweissmann.me) schrieb:
> 
>> I would also love to have generic associated types in the language, I have a 
>> lot of uses for them and, IIUC, supertype constraint would enable me to 
>> express the following:
>> 
>> protocol Service {}
>> 
>> protocol WikiService: Service {} // methods not shown for conciseness
>> class DefaultWikiService: WikiService {}
>> class DemoWikiService: WikiService {}
>> 
>> class DataServiceManager {
>> 
>> private var registry = [String: Service]()
>> 
>> func register(_ service: Service, ofType type: S.Type) where S: 
>> Service {
>> let key = "\(Swift.type(of: type))"
>> registry[key] = service
>> }
>> 
>> func service(ofType type: S.Type) -> S where S: Service {
>> let key = "\(Swift.type(of: type))"
>> 
>> // It is a programmer error to expect a value for a not yet 
>> registered type
>> guard let service = registry[key] as? S else {
>> fatalError("Service of type \(type) cannot be found. Please 
>> register a service for that type before accessing it.")
>> }
>> return service
>> }
>> 
>> }
>> 
>> let manager = DataServiceManager()
>> if isDemoMode {
>> manager.register(DemoWikiService(), ofType: WikiService.self) // 
>> Currently: error: in argument type 'WikiService.Protocol', 'WikiService' 
>> does not conform to expected type 'Service'
>> } else {
>> manager.register(DefaultWikiService(), ofType: WikiService.self) // 
>> Currently: error: in argument type 'WikiService.Protocol', 'WikiService' 
>> does not conform to expected type 'Service'
>> }
>> 
>> If that's right, I'm also +1 on this :)
>> 
>> - Dennis
>> 
>>> On Nov 25, 2017, at 12:13 AM, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> In general this is more then welcome, so +1 for me.
>>> 
>>> However I have one question:
>>> 
>>> Could this allow support, or at least be a first step towards Swift 
>>> allowing the following behaviour?
>>> 
>>> ```
>>> extension MyProtocol where Self : SomeClass {
>>> static func getSubtypes(ofType _: T.Type = T.self) -> [T] where T : Self 
>>> { ... }
>>> }
>>> ```
>>> 
>>> I would like to be able to upgrade `Self` to a class constraint, which then 
>>> will allow me to only accept subtypes from T at compile time.
>>> 
>>> Am 25. November 2017 um 00:03:23, Matthew Johnson via swift-evolution 
>>> (swift-evolution@swift.org) schrieb:
>>> 
 One of the most frequent frustrations I encounter when writing generic 
 code in Swift is the requirement that supertype constraints be concrete.  
 When I mentioned this on Twitter 
 (https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
 mentioned that this feature is smaller and mostly straightforward to 
 design and implement 
 (https://twitter.com/dgregor79/status/929975472779288576). 
 
 I currently have a PR open to add the high-level description of this 
 feature found below to the generics manifesto 
 (https://github.com/apple/swift/pull/13012):
 
 Currently, supertype constraints may only be specified using a concrete 
 class or protocol type.  This prevents us from abstracting over the 
 supertype.
 
 ```swift
 protocol P {
   associatedtype Base
   associatedtype Derived: Base
 }
 ```
 
 In the above example `Base` may be any type.  `Derived` may be the same as 
 `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
 supported by Swift 

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Adrian Zubarev via swift-evolution]

Well no, this proposal won’t allow your example. The problem in your example 
actually has different roots - *Metatypes*. As by today, meta types are somehow 
broken, especially in generic / associated type context. Furthermore there is 
currently no way to express that you may want a subtype for an existential 
metatype instead of the static metatype.

For more informations about meta types and who some of us would like them to 
work, read our proposal here:
https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md

Then your example could be expressed as:

```
func register(_ service: Service, ofType type: Type) where AnyType : 
AnyType {}

// or if I’m not mistaken we can make use if implicit existential like this then
func register(_ service: Service, ofType type: Type) where S : Service {}
```

I don't want to dive any deeper about the metatype pain points, because I don’t 
want to prevent the success of the pitched idea with an off-topic.


Am 25. November 2017 um 16:34:58, Dennis Weissmann (den...@dennisweissmann.me) 
schrieb:

I would also love to have generic associated types in the language, I have a 
lot of uses for them and, IIUC, supertype constraint would enable me to express 
the following:

protocol Service {}

protocol WikiService: Service {} // methods not shown for conciseness
class DefaultWikiService: WikiService {}
class DemoWikiService: WikiService {}

class DataServiceManager {

    private var registry = [String: Service]()

    func register(_ service: Service, ofType type: S.Type) where S: Service {
        let key = "\(Swift.type(of: type))"
        registry[key] = service
    }

    func service(ofType type: S.Type) -> S where S: Service {
        let key = "\(Swift.type(of: type))"

        // It is a programmer error to expect a value for a not yet registered 
type
        guard let service = registry[key] as? S else {
            fatalError("Service of type \(type) cannot be found. Please 
register a service for that type before accessing it.")
        }
        return service
    }

}

let manager = DataServiceManager()
if isDemoMode {
    manager.register(DemoWikiService(), ofType: WikiService.self) // Currently: 
error: in argument type 'WikiService.Protocol', 'WikiService' does not conform 
to expected type 'Service'
} else {
    manager.register(DefaultWikiService(), ofType: WikiService.self) // 
Currently: error: in argument type 'WikiService.Protocol', 'WikiService' does 
not conform to expected type 'Service'
}

If that's right, I'm also +1 on this :)

- Dennis

On Nov 25, 2017, at 12:13 AM, Adrian Zubarev via swift-evolution 
 wrote:

In general this is more then welcome, so +1 for me.

However I have one question:

Could this allow support, or at least be a first step towards Swift allowing 
the following behaviour?

```
extension MyProtocol where Self : SomeClass {
static func getSubtypes(ofType _: T.Type = T.self) -> [T] where T : Self { 
... }
}
```

I would like to be able to upgrade `Self` to a class constraint, which then 
will allow me to only accept subtypes from T at compile time.

Am 25. November 2017 um 00:03:23, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:

One of the most frequent frustrations I encounter when writing generic code in 
Swift is the requirement that supertype constraints be concrete.  When I 
mentioned this on Twitter 
(https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
mentioned that this feature is smaller and mostly straightforward to design and 
implement (https://twitter.com/dgregor79/status/929975472779288576).

I currently have a PR open to add the high-level description of this feature 
found below to the generics manifesto 
(https://github.com/apple/swift/pull/13012):

Currently, supertype constraints may only be specified using a concrete class 
or protocol type.  This prevents us from abstracting over the supertype.

```swift
protocol P {
  associatedtype Base
  associatedtype Derived: Base
}
```

In the above example `Base` may be any type.  `Derived` may be the same as 
`Base` or may be _any_ subtype of `Base`.  All subtype relationships supported 
by Swift should be supported in this context including, but not limited to, 
classes and subclasses, existentials and conforming concrete types or refining 
existentials, `T?` and  `T`, `((Base) -> Void)` and `((Derived) -> Void)`, etc.

Generalized supertype constraints would be accepted in all syntactic locations 
where generic constraints are accepted.

I would like to see generalized supertype constraints make it into Swift 5 if 
possible.  I am not an implementer so I will not be able to bring a proposal 
forward alone but am interested in collaborating with anyone interested in 
working on implementation.

I am also interested in hearing general feedback on this feature from the 
community at large.  Have you also found this limitation 

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Dennis Weissmann via swift-evolution]

I would also love to have generic associated types in the language, I have a 
lot of uses for them and, IIUC, supertype constraint would enable me to express 
the following:

protocol Service {}

protocol WikiService: Service {} // methods not shown for conciseness
class DefaultWikiService: WikiService {}
class DemoWikiService: WikiService {}

class DataServiceManager {

private var registry = [String: Service]()

func register(_ service: Service, ofType type: S.Type) where S: Service {
let key = "\(Swift.type(of: type))"
registry[key] = service
}

func service(ofType type: S.Type) -> S where S: Service {
let key = "\(Swift.type(of: type))"

// It is a programmer error to expect a value for a not yet registered 
type
guard let service = registry[key] as? S else {
fatalError("Service of type \(type) cannot be found. Please 
register a service for that type before accessing it.")
}
return service
}

}

let manager = DataServiceManager()
if isDemoMode {
manager.register(DemoWikiService(), ofType: WikiService.self) // Currently: 
error: in argument type 'WikiService.Protocol', 'WikiService' does not conform 
to expected type 'Service'
} else {
manager.register(DefaultWikiService(), ofType: WikiService.self) // 
Currently: error: in argument type 'WikiService.Protocol', 'WikiService' does 
not conform to expected type 'Service'
}

If that's right, I'm also +1 on this :)

- Dennis

> On Nov 25, 2017, at 12:13 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> In general this is more then welcome, so +1 for me.
> 
> However I have one question:
> 
> Could this allow support, or at least be a first step towards Swift allowing 
> the following behaviour?
> 
> ```
> extension MyProtocol where Self : SomeClass {
>   static func getSubtypes(ofType _: T.Type = T.self) -> [T] where T : 
> Self { ... }
> }
> ```
> 
> I would like to be able to upgrade `Self` to a class constraint, which then 
> will allow me to only accept subtypes from T at compile time.
> 
> Am 25. November 2017 um 00:03:23, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> One of the most frequent frustrations I encounter when writing generic code 
>> in Swift is the requirement that supertype constraints be concrete.  When I 
>> mentioned this on Twitter 
>> (https://twitter.com/anandabits/status/929958479598534656 
>> ) Doug Gregor 
>> mentioned that this feature is smaller and mostly straightforward to design 
>> and implement (https://twitter.com/dgregor79/status/929975472779288576 
>> ).
>> 
>> I currently have a PR open to add the high-level description of this feature 
>> found below to the generics manifesto 
>> (https://github.com/apple/swift/pull/13012 
>> ):
>> 
>> Currently, supertype constraints may only be specified using a concrete 
>> class or protocol type.  This prevents us from abstracting over the 
>> supertype.
>> 
>> ```swift
>> protocol P {
>>   associatedtype Base
>>   associatedtype Derived: Base
>> }
>> ```
>> 
>> In the above example `Base` may be any type.  `Derived` may be the same as 
>> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
>> supported by Swift should be supported in this context including, but not 
>> limited to, classes and subclasses, existentials and conforming concrete 
>> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
>> `((Derived) -> Void)`, etc.
>> 
>> Generalized supertype constraints would be accepted in all syntactic 
>> locations where generic constraints are accepted.
>> 
>> I would like to see generalized supertype constraints make it into Swift 5 
>> if possible.  I am not an implementer so I will not be able to bring a 
>> proposal forward alone but am interested in collaborating with anyone 
>> interested in working on implementation.
>> 
>> I am also interested in hearing general feedback on this feature from the 
>> community at large.  Have you also found this limitation frustrating?  In 
>> what contexts?  Does anyone have reservations about introducing this 
>> capability?  If so, what are they?
>> 
>> Matthew
>> 
>> ___
>> 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
swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Adrian Zubarev via swift-evolution]

In general this is more then welcome, so +1 for me.

However I have one question:

Could this allow support, or at least be a first step towards Swift allowing 
the following behaviour?

```
extension MyProtocol where Self : SomeClass {
static func getSubtypes(ofType _: T.Type = T.self) -> [T] where T : 
Self { ... }
}
```

I would like to be able to upgrade `Self` to a class constraint, which then 
will allow me to only accept subtypes from T at compile time.

Am 25. November 2017 um 00:03:23, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:

One of the most frequent frustrations I encounter when writing generic code in 
Swift is the requirement that supertype constraints be concrete.  When I 
mentioned this on Twitter 
(https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
mentioned that this feature is smaller and mostly straightforward to design and 
implement (https://twitter.com/dgregor79/status/929975472779288576).

I currently have a PR open to add the high-level description of this feature 
found below to the generics manifesto 
(https://github.com/apple/swift/pull/13012):

Currently, supertype constraints may only be specified using a concrete class 
or protocol type.  This prevents us from abstracting over the supertype.

```swift
protocol P {
  associatedtype Base
  associatedtype Derived: Base
}
```

In the above example `Base` may be any type.  `Derived` may be the same as 
`Base` or may be _any_ subtype of `Base`.  All subtype relationships supported 
by Swift should be supported in this context including, but not limited to, 
classes and subclasses, existentials and conforming concrete types or refining 
existentials, `T?` and  `T`, `((Base) -> Void)` and `((Derived) -> Void)`, etc.

Generalized supertype constraints would be accepted in all syntactic locations 
where generic constraints are accepted.

I would like to see generalized supertype constraints make it into Swift 5 if 
possible.  I am not an implementer so I will not be able to bring a proposal 
forward alone but am interested in collaborating with anyone interested in 
working on implementation.

I am also interested in hearing general feedback on this feature from the 
community at large.  Have you also found this limitation frustrating?  In what 
contexts?  Does anyone have reservations about introducing this capability?  If 
so, what are they?

Matthew

___
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