[swift-evolution] [Pitch] Generalized supertype constraints

[Rex Fenley]

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 <rex at 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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/15dc37a4/attachment.html>