[swift-evolution] Swift Generic Subtype Problem

Cao Jiannan frogcjn at 163.com
Mon Feb 15 23:26:19 CST 2016


I mean,

we only allow the class which not defined property like this kind of to has this feature.

or we only allow the system Optional type has this feature.

because Optional<B> is subclass of Optional<A>, this is very rational!


I think the problem is to implement optional with generic. 
There are many other ways to implement optional feature, use generic maybe a bad idea.


> 在 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/14b01f7f/attachment.html>


More information about the swift-evolution mailing list