[Pitch] Generalized supertype constraints

rex-remind · December 5, 2017, 11:34pm

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/anandabits/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 (Apple · GitHub
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.

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>

davidbjames · December 7, 2017, 10:46am

+1

It would be nice to have generic supertype constraints, with syntax along the lines of `where A:B`.

Not sure if this is the same as what’s being suggested.

Example:
struct ViewWrapper<T:UIView> {
    let views:[T]
    func add<V:UIView>(_ view:V) -> ViewWrapper<T> where V:T { // V must be a subtype of T
        let newViews = views + [view] // pseudo code
        return ViewWrapper(views: newViews)
    }
}
let controls = ViewWrapper<UIControl>(views:)
controls.add(UIButton()) // succeeds, UIButton is a UIControl
controls.add(UIView()) // fails, UIView is not a UIControl
David

···

On 6 Dec 2017, at 00:34, Rex Fenley via swift-evolution <swift-evolution@swift.org> 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/anandabits/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.
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 <mailto: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 <Facebook
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

David James

rex-remind · January 10, 2018, 8:19pm

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@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.
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
<Facebook;

--

Rex Fenley | IOS DEVELOPER

Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/>
> FOLLOW
US <https://twitter.com/remindhq> | LIKE US
<Facebook;

anandabits · January 10, 2018, 8:33pm

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.

Hi Rex, thank you for offering to help! I have not found anyone else to help out on implementation but am still extremely interested in seeing this happen and willing to help out by drafting the proposal, etc.

Is anyone who is familiar with it able to give Rex an idea of scope and / or willing to help Rex get up to speed?

···

On Jan 10, 2018, at 2:19 PM, Rex Fenley <rex@remind101.com> wrote:

On Tue, Dec 5, 2017 at 3:34 PM, Rex Fenley <rex@remind101.com <mailto:rex@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/anandabits/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.
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 <mailto: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 <Facebook;

--
Rex Fenley | IOS DEVELOPER

Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | FOLLOW US <https://twitter.com/remindhq> | LIKE US <Facebook;