[swift-evolution] Swift Generic Subtype Problem
Cao Jiannan
frogcjn at 163.com
Mon Feb 15 23:53:41 CST 2016
I think the best way to balance is only allowing sub-typing working with safe classes.
For example, the optional generic type which has no constant definition like the one in your example.
By the way, B? should also be subclass with A!, do you agree? This are tons of reasons for this.
Currently, Swift using as to convert this two types (! and ?), but I think they are really the same type.
So I think the problem is not from generic. The problem is from how Swift deal with optional.
> 在 2016年2月16日,13:20,Developer <devteam.codafi at gmail.com> 写道:
>
> OK, one type parameter then
>
> struct IO<A> { //... }
>
> struct Observer<A> {
> let unObserver : A -> IO<()>
> }
>
> Point is, if you're going to introduce variance it has to go both ways. That means you'll need something more in the language than a typing rule that just works in this one small case.
>
> ~Robert Widmann
>
> 2016/02/16 0:00、Cao Jiannan <frogcjn at 163.com <mailto:frogcjn at 163.com>> のメッセージ:
>
>> OK, let narrow the problem.
>>
>> if B is subclass of A
>> Optional<B> is subclass of Optional<A>
>>
>> Not allow multiple type template.
>>
>>
>>
>>
>>> 在 2016年2月16日,12:29,Developer <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> 写道:
>>>
>>> OK, so you have covariance covered, now what about contravariance? Surely a structure like this
>>>
>>> struct Arrow<A, B> {
>>> let unArrow : A -> B
>>> }
>>>
>>> should be contravariant in its first argument and covariant in its second.
>>>
>>> ~Robert Widmann
>>>
>>> 2016/02/15 22:48、Cao Jiannan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
>>>
>>>>
>>>> Hi all,
>>>> I want to discuss on a problem about optional generic sub-typing.
>>>>
>>>> This is my suggesion.
>>>>
>>>> if B is subclass of A
>>>> Either<B,B> is subclass of Either<A,A>, Either<A,B>, Either<B,A>
>>>> Either<B,A> is subclass of Either<A,A>
>>>> Either<A,B> is subclass of Either<A,A>
>>>>
>>>>
>>>> Why? Let’s see an example code in a real project:
>>>>
>>>>
>>>>
>>>> Here is a protocol type for some UIViewController,
>>>> protocol SegueHandlerType {
>>>> var tableView: UITableView! { get }
>>>> }
>>>>
>>>> so the UITableViewController can conform to the protocal
>>>> extension UITableViewController : SegueHandlerType {
>>>> }
>>>>
>>>> It's great!
>>>> What if the tableView is a subclass UITableView?
>>>> like:
>>>> class MyTableView : UITableView {
>>>> }
>>>>
>>>> MyTableViewController {
>>>> @IBOutlet var tableView: MyTableView!
>>>> }
>>>>
>>>> Then
>>>> extension MyTableViewController:SegueHandlerType {
>>>>
>>>> }
>>>> will trigger a compiler error.
>>>>
>>>> So the Optional needs a subclass system.
>>>> Or to say, that the template system needs a subclass system.
>>>>
>>>> Optional<UITableView> should be the super type of Optional<MyTableView>
>>>> Array<UITableView> should be the super type of Array<MyTableView>
>>>>
>>>> https://forums.developer.apple.com/message/101646#101646 <https://forums.developer.apple.com/message/101646#101646>
>>>>
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> Jiannan, Cao
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/87a1b13b/attachment.html>
More information about the swift-evolution
mailing list