[swift-evolution] Swift Generic Subtype Problem

[Andrew Bennett]

I think Union is a good solution as it's opt-in. The reason I'd want opt-in
is because the compiler could infer the data size at compile time and
possibly eliminate dynamic dispatch if the exact type is known. You'd
probably want a shorthand for the union though, for example:
    MyClass.typeUnion

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. 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.

On Tuesday, 16 February 2016, Cao Jiannan via swift-evolution <
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,
>
>    1. protocol  SegueHandlerType {
>    2.     var tableView: UITableView! { get }
>    3. }
>
>
> so the UITableViewController can conform to the protocal
>
>    1. extension UITableViewController : SegueHandlerType {
>    2. }
>
>
> It's great!
> What if the tableView is a subclass UITableView?
> like:
>
>    1. class MyTableView : UITableView {
>    2. }
>    3.
>    4. MyTableViewController {
>    5.       @IBOutlet var tableView: MyTableView!
>    6. }
>
>
> Then
>
>    1. extension MyTableViewController:SegueHandlerType {
>    2.
>    3. }
>
> 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
>
>
>
>
> Thanks!
>
> Jiannan, Cao
>
>
>
> _______________________________________________
> 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/7e72b173/attachment.html>