[swift-evolution] Swift Generic Subtype Problem

Tue Feb 16 02:37:44 CST 2016

Thanks for the detailed response, very interesting and its helped improve
my mental model. I think I may have misinterpreted the extent of the
proposal. Good point with CoreGraphics, I was the memory layout rather than
the public interface that I was thinking of, but perhaps my memory is out
of date :)

I think the thing I was remembering is this sort of thing:

public struct _opaque_pthread_t {

    public var __sig: Int

    public var __cleanup_stack: UnsafeMutablePointer<
__darwin_pthread_handler_rec>

    public var __opaque: (Int8, Int8, Int8, Int8, ...))

}

But I think that's a pthread thing, and probably for fixed sized arrays
too. Anyway tuples is for the other thread.

If my assumptions were false and the original idea doesn't change the
memory/performance overhead then I am all for it :)

On Tue, Feb 16, 2016 at 5:24 PM, Slava Pestov <spestov at apple.com> wrote:

>
> 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> 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
>>
>>
>>
>> _______________________________________________
> 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/e9e69269/attachment.html>