[swift-evolution] Swift Generic Subtype Problem

[Cao Jiannan]

Using Optional<Wrapped> generic leads to many problems, including this one.
Why subclass of UITableView cannot conform to this protocol? This is very weird.

protocol  SegueHandlerType {  
    var tableView: UITableView! { get }  
} 

The complex design of using generic to implement optional feature, leads to many problems.
What is the type relation between A!, A?, A and B!, B?, B (if B is subtype of A)
This made a clear answer hard to answer.

In my opinion, A!, A?, A should be the same class, the only difference is the runtime checking, 
not using the generic checking, because they are really the same type.

 


> 在 2016年2月16日，13:26，Cao Jiannan via swift-evolution <swift-evolution at swift.org> 写道：
> 
> 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 <mailto: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>
>>> 
> 
> _______________________________________________
> 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/aac37fa0/attachment.html>