[swift-evolution] Swift Generic Subtype Problem

[Slava Pestov]

> On Feb 15, 2016, at 11:46 PM, Andrew Bennett via swift-evolution <swift-evolution at swift.org> wrote:
> 
> The same goes for tuples. At the moment a tuple is the closest thing to a c style struct. I think c structs are currently imported as tuples.

Actually structs are imported as structs :-) (eg, import CoreGraphics - you get a CGPoint struct). We ask clang do the in-memory layout, but from a language perspective, they look mostly like normal Swift structs.

> If you made it so (A,A) was interchangeable with (B,B) then they'd have to have the same size, and maybe also store type information where they may not otherwise.

That’s not a requirement for subtyping relations actually.

If A is a struct conforming to some protocol P, then values of type ‘A’ have a different runtime representation than values of type ‘P’, because the protocol value needs to attach the runtime type to the payload, whereas the struct will not. However, we still do an implicit conversion allowing As to be passed as Ps, we just generate the right code at the point where the conversion takes place. 

Another example is when you have a function () -> A, the conversion to () -> P requires actually generating a thunk to wrap the original function value.

Subtyping in Swift is different from a pointer cast in C — its semantically producing a new value, so any representational change issues are orthogonal to the language itself. They leak out in the cases that are not implemented (we don’t do tuple conversions currently, and didn’t do function conversions until 2.1) but those will get plugged over time.

Slava

> 
> On Tuesday, 16 February 2016, Cao Jiannan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Also:
> 
> union(A,B,C) is subtype of union(A,B,C,D,…)
> 
>> 在 2016年2月16日，14:36，Cao Jiannan <frogcjn at 163.com <>> 写道：
>> 
>> Hi all,
>> 
>> I think the best way to solve the either problem is to separate it from generic. 
>> Optional and Either shouldn’t work the same way of generic type. 
>> It’s just a represent of multiple type in one location.
>> 
>> Using an old friend, Union in C.
>> union {
>> 	case firstType
>> 	case secondType
>> }
>> 
>> This is the final solution for the sub typing problem of optional.
>> 
>> 
>> A  == union(A,A)
>> union(A,B) == union(B,A)
>> B == union(B,B)
>> 
>> B is subtype of union(A,B)
>> A is subtype of union(A,B)
>> 
>> suppose 
>> a is subclass of A
>> b is subclass of B, then
>> 	union(a,B) is subtype of union(A,B)
>> 	union(A,b) is subtype of union(A,B)
>> 	union(a,b) is subtype of union(a,B)
>> 	union(a,b) is subtype of union(A,b)
>> 
>> union can have as many case as possible. e.g., union(A,B,C,D,…)
>> 
>> So the Optional<UITableView> should be union(UITableView, None)
>> and Optional<MyTableVIew> should be union(MyTableView, None), which is subclass of union(UITableView, None)
>> 
>> This is a final rational solution. I think.
>> 
>> -Jiannan
>> 
>>> 下面是被转发的邮件：
>>> 
>>> 发件人: Cao Jiannan via swift-evolution <swift-evolution at swift.org <>>
>>> 主题: [swift-evolution] Swift Generic Subtype Problem
>>> 日期: 2016年2月16日 GMT+8 11:48:18
>>> 收件人: swift-evolution at swift.org <>
>>> 回复－收件人: Cao Jiannan <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.
>>>  
>>> 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 <>
>>> 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/f9fd218d/attachment.html>