Re: [swift-evolution] Enhanced Existentials

2017-01-18 Thread Adrian Zubarev via swift-evolution
Here are a few thoughts on how I imagine these existentials to look like.

// We now write the `where` clause all the way at the end.
// SE-0142 does follow that route as well.
// I think there is no need for a leading dot in existentials, similar to the 
where clause from SE-0142.

typealias MyConstrainedView = Any where AssociatedType == 
SomeType

// Shorthand form
typealias MyConstrainedView = UIView & MyProtocol where AssociatedType == 
SomeType

// If there is a clash of two associated types with the same name, which both 
comes from a different protocol, we should be explicit there and prefix them 
with `ProtocolName.`

typealias A = Any where P1.AssociatedType == SomeType, 
P2.AssociatedType == SomeOtherType
Overlapping classes that share some subtype relationship should provide a 
fix-it warning and merge.

// Warning
Any

// Fixed
Any

// Simpler
UIView & SomeProtocol


-- 
Adrian Zubarev
Sent with Airmail

Am 18. Januar 2017 um 17:46:20, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

Hi there,

>From my current perspective, my draft is way to0 outdated and ugly. :D And I 
>myself will be very busy in the next two month, so please don’t count on me 
>for now.

But I will follow the topic and write some feedback as good as I only can.



-- 
Adrian Zubarev
Sent with Airmail

Am 18. Januar 2017 um 17:41:11, Austin Zheng (austinzh...@gmail.com) schrieb:

I probably won't have time, unfortunately. I think Adrian Zubarev (cc'ed) had a 
draft for this proposal at some point, so you might want to work with him.

Austin

On Jan 17, 2017, at 11:48 PM, David Hart  wrote:

Austin? Do you want/have time to split out the Superclass + Protocol proposal? 
If not, I can do it. Let me know.
David.

On 18 Jan 2017, at 00:27, Douglas Gregor  wrote:


On Jan 10, 2017, at 10:21 PM, David Hart  wrote:

What do you think I should do then? Start an official proposal for Superclass + 
Protocol because that’s all we can afford to have for Swift 4 or bug Austin to 
resubmit his full proposal?

I think it makes sense to split out the more-Swift-4-critical Superclass + 
Protocol bit, because it affects the import of Objective-C APIs in a manner 
that breaks source code. Reading the tea leaves, I can’t imagine having time to 
implement the full generalized-extensions proposal in Swift 4.

- Doug


David.

On 11 Jan 2017, at 00:09, Douglas Gregor  wrote:


On Jan 8, 2017, at 8:21 AM, David Hart  wrote:


On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
 wrote:



Sent from my iPhone

On Jan 6, 2017, at 11:04 PM, Russ Bishop  wrote:


On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
 wrote:



Would love to see this come forward into discussion.

Yeah. I'm less sure about the other enhancements to existentials fitting into 
Swift 4, e.g., the creation of existentials for protocols with associated 
types. Although important, it's a big feature that will take a bunch of design 
and implementation time, and I'm leery of accepting something that we might not 
actually be able to achieve. 

- Doug

By this are you referring to generalized existentials?

Yes. I actually prefer the term "generalized existentials".

If so I’ll say this is such a constant pain point and perverts so many API 
designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In my 
completely non-authoritative personal opinion we shouldn’t ship Swift 4 without 
it :)

To be absolutely clear, I think this is an extremely important feature. It's 
also a significant undertaking in both design and implementation. 

Hasn't most of the design work already been done by Austin and all those 
participating back then? What is missing? How much of the original proposal is 
possible to implement in the Swift 4 (on top of Superclass + Protocol)? Just 
want some hints on how to drive this so we can get as much of generalized 
existentials for Swift 4.

Yes, that’s fair: the proposal is in excellent shape, and I (personally) agree 
with most (maybe all) of the design decisions in it.

- Doug





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


Re: [swift-evolution] Enhanced Existentials

2017-01-18 Thread Adrian Zubarev via swift-evolution
Hi there,

>From my current perspective, my draft is way to0 outdated and ugly. :D And I 
>myself will be very busy in the next two month, so please don’t count on me 
>for now.

But I will follow the topic and write some feedback as good as I only can.



-- 
Adrian Zubarev
Sent with Airmail

Am 18. Januar 2017 um 17:41:11, Austin Zheng (austinzh...@gmail.com) schrieb:

I probably won't have time, unfortunately. I think Adrian Zubarev (cc'ed) had a 
draft for this proposal at some point, so you might want to work with him.

Austin

On Jan 17, 2017, at 11:48 PM, David Hart  wrote:

Austin? Do you want/have time to split out the Superclass + Protocol proposal? 
If not, I can do it. Let me know.
David.

On 18 Jan 2017, at 00:27, Douglas Gregor  wrote:


On Jan 10, 2017, at 10:21 PM, David Hart  wrote:

What do you think I should do then? Start an official proposal for Superclass + 
Protocol because that’s all we can afford to have for Swift 4 or bug Austin to 
resubmit his full proposal?

I think it makes sense to split out the more-Swift-4-critical Superclass + 
Protocol bit, because it affects the import of Objective-C APIs in a manner 
that breaks source code. Reading the tea leaves, I can’t imagine having time to 
implement the full generalized-extensions proposal in Swift 4.

- Doug


David.

On 11 Jan 2017, at 00:09, Douglas Gregor  wrote:


On Jan 8, 2017, at 8:21 AM, David Hart  wrote:


On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
 wrote:



Sent from my iPhone

On Jan 6, 2017, at 11:04 PM, Russ Bishop  wrote:


On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
 wrote:



Would love to see this come forward into discussion.

Yeah. I'm less sure about the other enhancements to existentials fitting into 
Swift 4, e.g., the creation of existentials for protocols with associated 
types. Although important, it's a big feature that will take a bunch of design 
and implementation time, and I'm leery of accepting something that we might not 
actually be able to achieve. 

- Doug

By this are you referring to generalized existentials?

Yes. I actually prefer the term "generalized existentials".

If so I’ll say this is such a constant pain point and perverts so many API 
designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In my 
completely non-authoritative personal opinion we shouldn’t ship Swift 4 without 
it :)

To be absolutely clear, I think this is an extremely important feature. It's 
also a significant undertaking in both design and implementation. 

Hasn't most of the design work already been done by Austin and all those 
participating back then? What is missing? How much of the original proposal is 
possible to implement in the Swift 4 (on top of Superclass + Protocol)? Just 
want some hints on how to drive this so we can get as much of generalized 
existentials for Swift 4.

Yes, that’s fair: the proposal is in excellent shape, and I (personally) agree 
with most (maybe all) of the design decisions in it.

- Doug





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


Re: [swift-evolution] Enhanced Existentials

2017-01-18 Thread Austin Zheng via swift-evolution
I probably won't have time, unfortunately. I think Adrian Zubarev (cc'ed) had a 
draft for this proposal at some point, so you might want to work with him.

Austin

> On Jan 17, 2017, at 11:48 PM, David Hart  wrote:
> 
> Austin? Do you want/have time to split out the Superclass + Protocol 
> proposal? If not, I can do it. Let me know.
> David.
> 
>> On 18 Jan 2017, at 00:27, Douglas Gregor > > wrote:
>> 
>> 
>>> On Jan 10, 2017, at 10:21 PM, David Hart >> > wrote:
>>> 
>>> What do you think I should do then? Start an official proposal for 
>>> Superclass + Protocol because that’s all we can afford to have for Swift 4 
>>> or bug Austin to resubmit his full proposal?
>> 
>> I think it makes sense to split out the more-Swift-4-critical Superclass + 
>> Protocol bit, because it affects the import of Objective-C APIs in a manner 
>> that breaks source code. Reading the tea leaves, I can’t imagine having time 
>> to implement the full generalized-extensions proposal in Swift 4.
>> 
>>  - Doug
>> 
>>> 
>>> David.
>>> 
 On 11 Jan 2017, at 00:09, Douglas Gregor >>> > wrote:
 
 
> On Jan 8, 2017, at 8:21 AM, David Hart  > wrote:
> 
>> 
>> On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Jan 6, 2017, at 11:04 PM, Russ Bishop >> > wrote:
>>> 
>>> 
 On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
> 
> Would love to see this come forward into discussion.
 
 Yeah. I'm less sure about the other enhancements to existentials 
 fitting into Swift 4, e.g., the creation of existentials for protocols 
 with associated types. Although important, it's a big feature that 
 will take a bunch of design and implementation time, and I'm leery of 
 accepting something that we might not actually be able to achieve. 
 
 - Doug
>>> 
>>> By this are you referring to generalized existentials?
>> 
>> Yes. I actually prefer the term "generalized existentials".
>> 
>>> If so I’ll say this is such a constant pain point and perverts so many 
>>> API designs… not to mention vomiting AnyXYZ type-erased wrappers 
>>> everywhere… In my completely non-authoritative personal opinion we 
>>> shouldn’t ship Swift 4 without it :)
>> 
>> To be absolutely clear, I think this is an extremely important feature. 
>> It's also a significant undertaking in both design and implementation. 
> 
> Hasn't most of the design work already been done by Austin and all those 
> participating back then? What is missing? How much of the original 
> proposal is possible to implement in the Swift 4 (on top of Superclass + 
> Protocol)? Just want some hints on how to drive this so we can get as 
> much of generalized existentials for Swift 4.
 
 
 Yes, that’s fair: the proposal is in excellent shape, and I (personally) 
 agree with most (maybe all) of the design decisions in it.
 
- Doug
 
>>> 
>> 
> 

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


Re: [swift-evolution] Enhanced Existentials

2017-01-17 Thread David Hart via swift-evolution
Austin? Do you want/have time to split out the Superclass + Protocol proposal? 
If not, I can do it. Let me know.
David.

> On 18 Jan 2017, at 00:27, Douglas Gregor  wrote:
> 
> 
>> On Jan 10, 2017, at 10:21 PM, David Hart > > wrote:
>> 
>> What do you think I should do then? Start an official proposal for 
>> Superclass + Protocol because that’s all we can afford to have for Swift 4 
>> or bug Austin to resubmit his full proposal?
> 
> I think it makes sense to split out the more-Swift-4-critical Superclass + 
> Protocol bit, because it affects the import of Objective-C APIs in a manner 
> that breaks source code. Reading the tea leaves, I can’t imagine having time 
> to implement the full generalized-extensions proposal in Swift 4.
> 
>   - Doug
> 
>> 
>> David.
>> 
>>> On 11 Jan 2017, at 00:09, Douglas Gregor >> > wrote:
>>> 
>>> 
 On Jan 8, 2017, at 8:21 AM, David Hart >>> > wrote:
 
> 
> On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jan 6, 2017, at 11:04 PM, Russ Bishop > > wrote:
>> 
>> 
>>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 
 Would love to see this come forward into discussion.
>>> 
>>> Yeah. I'm less sure about the other enhancements to existentials 
>>> fitting into Swift 4, e.g., the creation of existentials for protocols 
>>> with associated types. Although important, it's a big feature that will 
>>> take a bunch of design and implementation time, and I'm leery of 
>>> accepting something that we might not actually be able to achieve. 
>>> 
>>> - Doug
>> 
>> By this are you referring to generalized existentials?
> 
> Yes. I actually prefer the term "generalized existentials".
> 
>> If so I’ll say this is such a constant pain point and perverts so many 
>> API designs… not to mention vomiting AnyXYZ type-erased wrappers 
>> everywhere… In my completely non-authoritative personal opinion we 
>> shouldn’t ship Swift 4 without it :)
> 
> To be absolutely clear, I think this is an extremely important feature. 
> It's also a significant undertaking in both design and implementation. 
 
 Hasn't most of the design work already been done by Austin and all those 
 participating back then? What is missing? How much of the original 
 proposal is possible to implement in the Swift 4 (on top of Superclass + 
 Protocol)? Just want some hints on how to drive this so we can get as much 
 of generalized existentials for Swift 4.
>>> 
>>> 
>>> Yes, that’s fair: the proposal is in excellent shape, and I (personally) 
>>> agree with most (maybe all) of the design decisions in it.
>>> 
>>> - Doug
>>> 
>> 
> 

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


Re: [swift-evolution] Enhanced Existentials

2017-01-17 Thread Jonathan Hull via swift-evolution
+1 for breaking it into manageable pieces so we can get moving on any design 
tweaks that need to happen and start implementing. This seems to be holding up 
a lot of good proposals.

Thanks,
Jon

> On Jan 17, 2017, at 3:27 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Jan 10, 2017, at 10:21 PM, David Hart > > wrote:
>> 
>> What do you think I should do then? Start an official proposal for 
>> Superclass + Protocol because that’s all we can afford to have for Swift 4 
>> or bug Austin to resubmit his full proposal?
> 
> I think it makes sense to split out the more-Swift-4-critical Superclass + 
> Protocol bit, because it affects the import of Objective-C APIs in a manner 
> that breaks source code. Reading the tea leaves, I can’t imagine having time 
> to implement the full generalized-extensions proposal in Swift 4.
> 
>   - Doug
> 
>> 
>> David.
>> 
>>> On 11 Jan 2017, at 00:09, Douglas Gregor >> > wrote:
>>> 
>>> 
 On Jan 8, 2017, at 8:21 AM, David Hart >>> > wrote:
 
> 
> On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jan 6, 2017, at 11:04 PM, Russ Bishop > > wrote:
>> 
>> 
>>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 
 Would love to see this come forward into discussion.
>>> 
>>> Yeah. I'm less sure about the other enhancements to existentials 
>>> fitting into Swift 4, e.g., the creation of existentials for protocols 
>>> with associated types. Although important, it's a big feature that will 
>>> take a bunch of design and implementation time, and I'm leery of 
>>> accepting something that we might not actually be able to achieve. 
>>> 
>>> - Doug
>> 
>> By this are you referring to generalized existentials?
> 
> Yes. I actually prefer the term "generalized existentials".
> 
>> If so I’ll say this is such a constant pain point and perverts so many 
>> API designs… not to mention vomiting AnyXYZ type-erased wrappers 
>> everywhere… In my completely non-authoritative personal opinion we 
>> shouldn’t ship Swift 4 without it :)
> 
> To be absolutely clear, I think this is an extremely important feature. 
> It's also a significant undertaking in both design and implementation. 
 
 Hasn't most of the design work already been done by Austin and all those 
 participating back then? What is missing? How much of the original 
 proposal is possible to implement in the Swift 4 (on top of Superclass + 
 Protocol)? Just want some hints on how to drive this so we can get as much 
 of generalized existentials for Swift 4.
>>> 
>>> 
>>> Yes, that’s fair: the proposal is in excellent shape, and I (personally) 
>>> agree with most (maybe all) of the design decisions in it.
>>> 
>>> - Doug
>>> 
>> 
> 
> ___
> 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] Enhanced Existentials

2017-01-17 Thread Douglas Gregor via swift-evolution

> On Jan 10, 2017, at 10:21 PM, David Hart  wrote:
> 
> What do you think I should do then? Start an official proposal for Superclass 
> + Protocol because that’s all we can afford to have for Swift 4 or bug Austin 
> to resubmit his full proposal?

I think it makes sense to split out the more-Swift-4-critical Superclass + 
Protocol bit, because it affects the import of Objective-C APIs in a manner 
that breaks source code. Reading the tea leaves, I can’t imagine having time to 
implement the full generalized-extensions proposal in Swift 4.

- Doug

> 
> David.
> 
>> On 11 Jan 2017, at 00:09, Douglas Gregor > > wrote:
>> 
>> 
>>> On Jan 8, 2017, at 8:21 AM, David Hart >> > wrote:
>>> 
 
 On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
 
 Sent from my iPhone
 
> On Jan 6, 2017, at 11:04 PM, Russ Bishop  > wrote:
> 
> 
>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> 
>>> Would love to see this come forward into discussion.
>> 
>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>> into Swift 4, e.g., the creation of existentials for protocols with 
>> associated types. Although important, it's a big feature that will take 
>> a bunch of design and implementation time, and I'm leery of accepting 
>> something that we might not actually be able to achieve. 
>> 
>> - Doug
> 
> By this are you referring to generalized existentials?
 
 Yes. I actually prefer the term "generalized existentials".
 
> If so I’ll say this is such a constant pain point and perverts so many 
> API designs… not to mention vomiting AnyXYZ type-erased wrappers 
> everywhere… In my completely non-authoritative personal opinion we 
> shouldn’t ship Swift 4 without it :)
 
 To be absolutely clear, I think this is an extremely important feature. 
 It's also a significant undertaking in both design and implementation. 
>>> 
>>> Hasn't most of the design work already been done by Austin and all those 
>>> participating back then? What is missing? How much of the original proposal 
>>> is possible to implement in the Swift 4 (on top of Superclass + Protocol)? 
>>> Just want some hints on how to drive this so we can get as much of 
>>> generalized existentials for Swift 4.
>> 
>> 
>> Yes, that’s fair: the proposal is in excellent shape, and I (personally) 
>> agree with most (maybe all) of the design decisions in it.
>> 
>>  - Doug
>> 
> 

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


Re: [swift-evolution] Enhanced Existentials

2017-01-10 Thread Austin Zheng via swift-evolution
I've been watching this thread and am happy to help if necessary, whatever the 
consensus is.

Austin

> On Jan 10, 2017, at 10:21 PM, David Hart via swift-evolution 
>  wrote:
> 
> What do you think I should do then? Start an official proposal for Superclass 
> + Protocol because that’s all we can afford to have for Swift 4 or bug Austin 
> to resubmit his full proposal?
> 
> David.
> 
>> On 11 Jan 2017, at 00:09, Douglas Gregor > > wrote:
>> 
>> 
>>> On Jan 8, 2017, at 8:21 AM, David Hart >> > wrote:
>>> 
 
 On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
 
 Sent from my iPhone
 
> On Jan 6, 2017, at 11:04 PM, Russ Bishop  > wrote:
> 
> 
>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> 
>>> Would love to see this come forward into discussion.
>> 
>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>> into Swift 4, e.g., the creation of existentials for protocols with 
>> associated types. Although important, it's a big feature that will take 
>> a bunch of design and implementation time, and I'm leery of accepting 
>> something that we might not actually be able to achieve. 
>> 
>> - Doug
> 
> By this are you referring to generalized existentials?
 
 Yes. I actually prefer the term "generalized existentials".
 
> If so I’ll say this is such a constant pain point and perverts so many 
> API designs… not to mention vomiting AnyXYZ type-erased wrappers 
> everywhere… In my completely non-authoritative personal opinion we 
> shouldn’t ship Swift 4 without it :)
 
 To be absolutely clear, I think this is an extremely important feature. 
 It's also a significant undertaking in both design and implementation. 
>>> 
>>> Hasn't most of the design work already been done by Austin and all those 
>>> participating back then? What is missing? How much of the original proposal 
>>> is possible to implement in the Swift 4 (on top of Superclass + Protocol)? 
>>> Just want some hints on how to drive this so we can get as much of 
>>> generalized existentials for Swift 4.
>> 
>> 
>> Yes, that’s fair: the proposal is in excellent shape, and I (personally) 
>> agree with most (maybe all) of the design decisions in it.
>> 
>>  - Doug
>> 
> 
> ___
> 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] Enhanced Existentials

2017-01-10 Thread David Hart via swift-evolution
What do you think I should do then? Start an official proposal for Superclass + 
Protocol because that’s all we can afford to have for Swift 4 or bug Austin to 
resubmit his full proposal?

David.

> On 11 Jan 2017, at 00:09, Douglas Gregor  wrote:
> 
> 
>> On Jan 8, 2017, at 8:21 AM, David Hart > > wrote:
>> 
>>> 
>>> On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On Jan 6, 2017, at 11:04 PM, Russ Bishop >>> > wrote:
 
 
> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
>> 
>> Would love to see this come forward into discussion.
> 
> Yeah. I'm less sure about the other enhancements to existentials fitting 
> into Swift 4, e.g., the creation of existentials for protocols with 
> associated types. Although important, it's a big feature that will take a 
> bunch of design and implementation time, and I'm leery of accepting 
> something that we might not actually be able to achieve. 
> 
> - Doug
 
 By this are you referring to generalized existentials?
>>> 
>>> Yes. I actually prefer the term "generalized existentials".
>>> 
 If so I’ll say this is such a constant pain point and perverts so many API 
 designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… 
 In my completely non-authoritative personal opinion we shouldn’t ship 
 Swift 4 without it :)
>>> 
>>> To be absolutely clear, I think this is an extremely important feature. 
>>> It's also a significant undertaking in both design and implementation. 
>> 
>> Hasn't most of the design work already been done by Austin and all those 
>> participating back then? What is missing? How much of the original proposal 
>> is possible to implement in the Swift 4 (on top of Superclass + Protocol)? 
>> Just want some hints on how to drive this so we can get as much of 
>> generalized existentials for Swift 4.
> 
> 
> Yes, that’s fair: the proposal is in excellent shape, and I (personally) 
> agree with most (maybe all) of the design decisions in it.
> 
>   - Doug
> 

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


Re: [swift-evolution] Enhanced Existentials

2017-01-10 Thread Braeden Profile via swift-evolution
Looking at that proposal on Austin’s Github, would its complete implementation 
require/allow for any type that’s known at runtime to be used like a type at 
compile time?  So that these two blocks would both work?  It seems like the 
runtime would be using the same technology, but it’s hard to tell.
let a : Collection where .Element == Int = // ...
let b : Collection where .Element == Int = // ...

func someGenericFunc(x: C, y: C) where C.Element == Int {
// ...
}

if let openedA = a as? a.Self, let openedB = b as? a.Self {
// openedA is type a.Self; openedB is type a.Self
// We now know that openedA and openedB are the same concrete type, which
// conforms to Collection with Elements that are Ints
// This is okay
someGenericFunc(x: openedA, y: openedB)
}
let a : Collection where .Element == Int = // ...
let b : Collection where .Element == Int = // ...

func someGenericFunc(x: C, y: C) where C.Element == Int {
// ...
}

let desiredType = type(of: a)
if let openedA = a as? desiredType, let openedB = b as? desiredType {
// openedA is type a.Self; openedB is type a.Self
// We now know that openedA and openedB are the same concrete type, which
// conforms to Collection with Elements that are Ints
// This is okay
someGenericFunc(x: openedA, y: openedB)
}

assert(type(of: a) === a.Self.self)

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


Re: [swift-evolution] Enhanced Existentials

2017-01-10 Thread Douglas Gregor via swift-evolution

> On Jan 8, 2017, at 8:21 AM, David Hart  wrote:
> 
>> 
>> On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Jan 6, 2017, at 11:04 PM, Russ Bishop  wrote:
>>> 
>>> 
 On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
  wrote:
 
 
> 
> Would love to see this come forward into discussion.
 
 Yeah. I'm less sure about the other enhancements to existentials fitting 
 into Swift 4, e.g., the creation of existentials for protocols with 
 associated types. Although important, it's a big feature that will take a 
 bunch of design and implementation time, and I'm leery of accepting 
 something that we might not actually be able to achieve. 
 
 - Doug
>>> 
>>> By this are you referring to generalized existentials?
>> 
>> Yes. I actually prefer the term "generalized existentials".
>> 
>>> If so I’ll say this is such a constant pain point and perverts so many API 
>>> designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In 
>>> my completely non-authoritative personal opinion we shouldn’t ship Swift 4 
>>> without it :)
>> 
>> To be absolutely clear, I think this is an extremely important feature. It's 
>> also a significant undertaking in both design and implementation. 
> 
> Hasn't most of the design work already been done by Austin and all those 
> participating back then? What is missing? How much of the original proposal 
> is possible to implement in the Swift 4 (on top of Superclass + Protocol)? 
> Just want some hints on how to drive this so we can get as much of 
> generalized existentials for Swift 4.


Yes, that’s fair: the proposal is in excellent shape, and I (personally) agree 
with most (maybe all) of the design decisions in it.

- Doug

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


Re: [swift-evolution] Enhanced Existentials

2017-01-09 Thread Russ Bishop via swift-evolution

> On Jan 7, 2017, at 9:17 PM, Douglas Gregor  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jan 6, 2017, at 11:04 PM, Russ Bishop  wrote:
>> 
>> 
>>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> 
 
 Would love to see this come forward into discussion.
>>> 
>>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>>> into Swift 4, e.g., the creation of existentials for protocols with 
>>> associated types. Although important, it's a big feature that will take a 
>>> bunch of design and implementation time, and I'm leery of accepting 
>>> something that we might not actually be able to achieve. 
>>> 
>>> - Doug
>> 
>> By this are you referring to generalized existentials?
> 
> Yes. I actually prefer the term "generalized existentials".
> 
>> If so I’ll say this is such a constant pain point and perverts so many API 
>> designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In 
>> my completely non-authoritative personal opinion we shouldn’t ship Swift 4 
>> without it :)
> 
> To be absolutely clear, I think this is an extremely important feature. It's 
> also a significant undertaking in both design and implementation. 

If I could wish for just one pony this year…. ;)


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


Re: [swift-evolution] Enhanced Existentials

2017-01-08 Thread David Hart via swift-evolution

> On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jan 6, 2017, at 11:04 PM, Russ Bishop  wrote:
>> 
>> 
>>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> 
 
 Would love to see this come forward into discussion.
>>> 
>>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>>> into Swift 4, e.g., the creation of existentials for protocols with 
>>> associated types. Although important, it's a big feature that will take a 
>>> bunch of design and implementation time, and I'm leery of accepting 
>>> something that we might not actually be able to achieve. 
>>> 
>>> - Doug
>> 
>> By this are you referring to generalized existentials?
> 
> Yes. I actually prefer the term "generalized existentials".
> 
>> If so I’ll say this is such a constant pain point and perverts so many API 
>> designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In 
>> my completely non-authoritative personal opinion we shouldn’t ship Swift 4 
>> without it :)
> 
> To be absolutely clear, I think this is an extremely important feature. It's 
> also a significant undertaking in both design and implementation. 

Hasn't most of the design work already been done by Austin and all those 
participating back then? What is missing? How much of the original proposal is 
possible to implement in the Swift 4 (on top of Superclass + Protocol)? Just 
want some hints on how to drive this so we can get as much of generalized 
existentials for Swift 4.

>  - Doug
> 
> ___
> 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] Enhanced Existentials

2017-01-07 Thread Douglas Gregor via swift-evolution


Sent from my iPhone

> On Jan 6, 2017, at 11:04 PM, Russ Bishop  wrote:
> 
> 
>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
>>> 
>>> Would love to see this come forward into discussion.
>> 
>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>> into Swift 4, e.g., the creation of existentials for protocols with 
>> associated types. Although important, it's a big feature that will take a 
>> bunch of design and implementation time, and I'm leery of accepting 
>> something that we might not actually be able to achieve. 
>> 
>>  - Doug
> 
> By this are you referring to generalized existentials?

Yes. I actually prefer the term "generalized existentials".

> If so I’ll say this is such a constant pain point and perverts so many API 
> designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In 
> my completely non-authoritative personal opinion we shouldn’t ship Swift 4 
> without it :)

To be absolutely clear, I think this is an extremely important feature. It's 
also a significant undertaking in both design and implementation. 

  - Doug

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


Re: [swift-evolution] Enhanced Existentials

2017-01-07 Thread Karl Wagner via swift-evolution

> On 7 Jan 2017, at 08:04, Russ Bishop via swift-evolution 
>  wrote:
> 
> 
>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
>>> 
>>> Would love to see this come forward into discussion.
>> 
>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>> into Swift 4, e.g., the creation of existentials for protocols with 
>> associated types. Although important, it's a big feature that will take a 
>> bunch of design and implementation time, and I'm leery of accepting 
>> something that we might not actually be able to achieve. 
>> 
>>  - Doug
> 
> By this are you referring to generalized existentials? If so I’ll say this is 
> such a constant pain point and perverts so many API designs… not to mention 
> vomiting AnyXYZ type-erased wrappers everywhere… In my completely 
> non-authoritative personal opinion we shouldn’t ship Swift 4 without it :)
> 
> 
> Russ
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


There is one little thing we could do to make that easier to live with: we 
could allow closure properties to satisfy function requirements on protocols.

It’s on my wishlist of things to propose in phase 2: 
https://gist.github.com/karwa/52b35a8a1f3bebc24264df5aeb2aa761#allow-function-requirements-in-protocols-to-be-satisfied-by-closure-type-properties

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


Re: [swift-evolution] Enhanced Existentials

2017-01-06 Thread Russ Bishop via swift-evolution

> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> 
>> Would love to see this come forward into discussion.
> 
> Yeah. I'm less sure about the other enhancements to existentials fitting into 
> Swift 4, e.g., the creation of existentials for protocols with associated 
> types. Although important, it's a big feature that will take a bunch of 
> design and implementation time, and I'm leery of accepting something that we 
> might not actually be able to achieve. 
> 
>   - Doug

By this are you referring to generalized existentials? If so I’ll say this is 
such a constant pain point and perverts so many API designs… not to mention 
vomiting AnyXYZ type-erased wrappers everywhere… In my completely 
non-authoritative personal opinion we shouldn’t ship Swift 4 without it :)


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


Re: [swift-evolution] Enhanced Existentials

2017-01-04 Thread David Sweeris via swift-evolution

> On Jan 4, 2017, at 21:28, Douglas Gregor  wrote:
> 
>> On Jan 4, 2017, at 9:19 PM, David Sweeris  wrote:
>> 
>> On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>>> into Swift 4, e.g., the creation of existentials for protocols with 
>>> associated types. Although important, it's a big feature that will take a 
>>> bunch of design and implementation time, and I'm leery of accepting 
>>> something that we might not actually be able to achieve.
>> 
>> If it's a feature we know we want, it seems that nailing the syntax down, 
>> even if we know there isn't time to actually fully implement it in 4.0, 
>> would be beneficial simply to prevent it from being a source-breaking change 
>> in 4.1.
> 
> Well, there is an opportunity cost to designing something that you know won’t 
> get implemented. That said, I won’t try to actually stop anyone from 
> discussing such a much-needed feature; I just might not participate much.

That's not a bad point. Ideally we'll either have the time to completely 
implement it for 4.0, or "prove" it can be implemented later without risking 
source-compatibility.

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


Re: [swift-evolution] Enhanced Existentials

2017-01-04 Thread Douglas Gregor via swift-evolution

> On Jan 4, 2017, at 9:19 PM, David Sweeris  wrote:
> 
> 
> On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>> into Swift 4, e.g., the creation of existentials for protocols with 
>> associated types. Although important, it's a big feature that will take a 
>> bunch of design and implementation time, and I'm leery of accepting 
>> something that we might not actually be able to achieve.
> 
> If it's a feature we know we want, it seems that nailing the syntax down, 
> even if we know there isn't time to actually fully implement it in 4.0, would 
> be beneficial simply to prevent it from being a source-breaking change in 4.1.

Well, there is an opportunity cost to designing something that you know won’t 
get implemented. That said, I won’t try to actually stop anyone from discussing 
such a much-needed feature; I just might not participate much.

- Doug


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


Re: [swift-evolution] Enhanced Existentials

2017-01-04 Thread David Sweeris via swift-evolution

> On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Yeah. I'm less sure about the other enhancements to existentials fitting into 
> Swift 4, e.g., the creation of existentials for protocols with associated 
> types. Although important, it's a big feature that will take a bunch of 
> design and implementation time, and I'm leery of accepting something that we 
> might not actually be able to achieve.

If it's a feature we know we want, it seems that nailing the syntax down, even 
if we know there isn't time to actually fully implement it in 4.0, would be 
beneficial simply to prevent it from being a source-breaking change in 4.1.

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


Re: [swift-evolution] Enhanced Existentials

2017-01-04 Thread Douglas Gregor via swift-evolution


Sent from my iPhone

> On Jan 3, 2017, at 10:08 PM, Rod Brown via swift-evolution 
>  wrote:
> 
>> On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution 
>>  wrote:
>> 
>> Hello Mailing-list,
>> 
>> I remember we discussed enhanced existentials heavily during the Swift 3 
>> timeframe but postponed it. I was wondering if we need to bring back for 
>> discussion during Phase 1 or Phase 2? For reference, here is the proposal 
>> which Austin Zhend wrote which represented the culmination of the 
>> discussions:
>> 
>> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md#nested-typealias-existential
>> 
>> Regards,
>> David.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I'm a big proponent of this - it's a limitation that is actually more capable 
> in Obj-C than it is in Swift, and considering Swift's increased focus on 
> Protocols, this seems rather baffling!

Yes. My personal feeling on this is that the ability to create an existential 
type with both superclass and protocol constraints is something we should 
address in Swift 4, because Objective-C APIs that use the feature (e.g., have a 
type like UIController) get weakened when they come into 
Swift. Fixing it is a source-breaking change, and I want to get it out of the 
way in Swift 4. 


> 
> Would love to see this come forward into discussion.

Yeah. I'm less sure about the other enhancements to existentials fitting into 
Swift 4, e.g., the creation of existentials for protocols with associated 
types. Although important, it's a big feature that will take a bunch of design 
and implementation time, and I'm leery of accepting something that we might not 
actually be able to achieve. 

  - Doug

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


Re: [swift-evolution] Enhanced Existentials

2017-01-03 Thread Rod Brown via swift-evolution
> On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution 
>  wrote:
> 
> Hello Mailing-list,
> 
> I remember we discussed enhanced existentials heavily during the Swift 3 
> timeframe but postponed it. I was wondering if we need to bring back for 
> discussion during Phase 1 or Phase 2? For reference, here is the proposal 
> which Austin Zhend wrote which represented the culmination of the discussions:
> 
> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md#nested-typealias-existential
> 
> Regards,
> David.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I'm a big proponent of this - it's a limitation that is actually more capable 
in Obj-C than it is in Swift, and considering Swift's increased focus on 
Protocols, this seems rather baffling!

Would love to see this come forward into discussion.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


[swift-evolution] Enhanced Existentials

2017-01-03 Thread David Hart via swift-evolution
Hello Mailing-list,

I remember we discussed enhanced existentials heavily during the Swift 3 
timeframe but postponed it. I was wondering if we need to bring back for 
discussion during Phase 1 or Phase 2? For reference, here is the proposal which 
Austin Zhend wrote which represented the culmination of the discussions:

https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md#nested-typealias-existential
 


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