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:
Regards,
David.
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.
On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution <swift-evolution@swift.org> 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:
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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:
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolutionI'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<UIWhateveDelegate>) 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
Sent from my iPhone
On Jan 3, 2017, at 10:08 PM, Rod Brown via swift-evolution <swift-evolution@swift.org> wrote:
On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
_______________________________________________
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
On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution <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.
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
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <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
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
On Jan 4, 2017, at 9:19 PM, David Sweeris <davesweeris@mac.com> wrote:
On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution <swift-evolution@swift.org <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.
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: Ideas for Swift 4 · GitHub
- Karl
<Ideas for Swift 4 · GitHub;
On 7 Jan 2017, at 08:04, Russ Bishop via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <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? 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
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
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
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
On Jan 4, 2017, at 21:28, Douglas Gregor <dgregor@apple.com> wrote:
On Jan 4, 2017, at 9:19 PM, David Sweeris <davesweeris@mac.com> wrote:
On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution <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.
Sent from my iPhone
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.
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
- Doug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
If I could wish for just one pony this year…. ;)
Russ
On Jan 7, 2017, at 9:17 PM, Douglas Gregor <dgregor@apple.com> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <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.
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
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <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.
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 <dgregor@apple.com> wrote:
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com <mailto:xenadu@gmail.com>> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <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
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 <swift-evolution@swift.org> 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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com <mailto:xenadu@gmail.com>> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <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
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
On Jan 10, 2017, at 10:21 PM, David Hart <david@hartbit.com> wrote:
David.
On 11 Jan 2017, at 00:09, Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com <mailto:xenadu@gmail.com>> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <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
+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 <swift-evolution@swift.org> wrote:
On Jan 10, 2017, at 10:21 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com <mailto:xenadu@gmail.com>> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <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
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 <dgregor@apple.com> wrote:
On Jan 10, 2017, at 10:21 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com <mailto:xenadu@gmail.com>> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <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
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 <david@hartbit.com> 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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
On Jan 10, 2017, at 10:21 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com <mailto:xenadu@gmail.com>> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <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
Hi there,
But I will follow the topic and write some feedback as good as I only can.
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.
--
Adrian Zubarev
Sent with Airmail
Am 18. Januar 2017 um 17:41:11, Austin Zheng (austinzheng@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 <david@hartbit.com> 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 <dgregor@apple.com> wrote:
On Jan 10, 2017, at 10:21 PM, David Hart <david@hartbit.com> 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 <dgregor@apple.com> wrote:
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <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
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<UIView, MyProtocol> 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<P1, P2> where P1.AssociatedType == SomeType, P2.AssociatedType == SomeOtherType
Overlapping classes that share some subtype relationship should provide a fix-it warning and merge.
// Warning
Any<UIView, NSObject, SomeProtocol>
// Fixed
Any<UIView, SomeProtocol>
// Simpler
UIView & SomeProtocol
--
Adrian Zubarev
Sent with Airmail
Am 18. Januar 2017 um 17:46:20, Adrian Zubarev (adrian.zubarev@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 (austinzheng@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 <david@hartbit.com> 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 <dgregor@apple.com> wrote:
On Jan 10, 2017, at 10:21 PM, David Hart <david@hartbit.com> 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 <dgregor@apple.com> wrote:
On Jan 8, 2017, at 8:21 AM, David Hart <david@hartbit.com> wrote:
On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPhone
On Jan 6, 2017, at 11:04 PM, Russ Bishop <xenadu@gmail.com> wrote:
On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution <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