[swift-evolution] Swift Generic Subtype Problem

Slava Pestov spestov at apple.com
Tue Feb 16 02:18:17 CST 2016


Hi Cao,

Note that Optional<T> already supports covariance as well as an “injection” from T to Optional<T>:

class A{

}

class B:A {

}

let b: B? = B()  // conversion from B to B?
let a: A? = b    // conversion from B? to A?

This is special-cased by the type checker, and not exposed for use by user-defined types such as Either in your example.

 
> On Feb 15, 2016, at 10:36 PM, Cao Jiannan via swift-evolution <swift-evolution at swift.org> wrote:
> 
> So the Optional<UITableView> should be union(UITableView, None)
> and Optional<MyTableVIew> should be union(MyTableView, None), which is subclass of union(UITableView, None)

But you can still have generic type parameters here, if your function is generic over T and you write union(T, SomeOtherType). How would that work?

> 
> This is a final rational solution. I think.
> 
> -Jiannan
> 
>> 下面是被转发的邮件:
>> 
>> 发件人: Cao Jiannan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>> 主题: [swift-evolution] Swift Generic Subtype Problem
>> 日期: 2016年2月16日 GMT+8 11:48:18
>> 收件人: swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> 回复-收件人: Cao Jiannan <frogcjn at 163.com <mailto:frogcjn at 163.com>>
>> 
>> 
>> 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.

The issue here is slightly different actually, but another interesting corner case that should be addressed. Protocol witness matching only looks at exact type equivalence, and not subtyping. So even without the ! it would hit the same issue:

protocol P {
	func f() -> A
}

class B : A {}

class C : P {
	func f() -> B {} // compile error
}

Once witness matching supports variance, your example will work.

But a better way would be to use an associated type:

protocol SequeHandlerType {
    associatedtype View : UITableView
    var tableView: View! { get }
}

Now a witness can return any subclass of UITableView, which will unify with the View associated type. Furthermore, other requirements can also reference View and the type checker will ensure any conformance has the same View in all positions where it appears.

Slava


>>  
>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/e1a3ab79/attachment.html>


More information about the swift-evolution mailing list