[swift-evolution] Swift Generic Subtype Problem
Slava Pestov
spestov at apple.com
Tue Feb 16 02:41:27 CST 2016
> On Feb 16, 2016, at 12:37 AM, Andrew Bennett <cacoyi at gmail.com> wrote:
>
> 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.
Yep, it’s fixed size arrays that are imported like that. We have no other way of modeling them in Swift right now.
> 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 :)
In general, the only things in the current Swift implementation that are tagged with runtime type information are instances of classes in the heap, and values of protocol type. Everywhere else, the compiler knows the layout statically, or it is passed in separately from the data (ie generics).
>
>
> On Tue, Feb 16, 2016 at 5:24 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>
>> On Feb 15, 2016, at 11:46 PM, Andrew Bennett via swift-evolution <swift-evolution at swift.org <mailto: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 <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/716bce26/attachment.html>
More information about the swift-evolution
mailing list