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.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 <da...@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 <dgre...@apple.com> wrote: On Jan 10, 2017, at 10:21 PM, David Hart <da...@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 <dgre...@apple.com> wrote: On Jan 8, 2017, at 8:21 AM, David Hart <da...@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 <xen...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
