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 <r...@remind101.com> 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 <https://www.remind.com/> | BLOG <http://blog.remind.com/> | > FOLLOW US <https://twitter.com/remindhq> | LIKE US > <https://www.facebook.com/remindhq> > -- Rex Fenley | IOS DEVELOPER Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | FOLLOW US <https://twitter.com/remindhq> | LIKE US <https://www.facebook.com/remindhq>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution