+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
> <[email protected]> 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
>> <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
>> <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
>> <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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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>_______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
David James
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
