On Fri, Jun 23, 2017 at 17:59 Mike Kluev via swift-evolution < [email protected]> wrote:
> On 23 June 2017 at 23:18, Tony Allevato <[email protected]> wrote: > >> class C1: C2 ==> C1() is C2 == true >> class C1: P ==> C1() is P == true >> class C1: S ==> C1() is S == false? >> > > ok. changing the rule then: > > C() is S == true > > foo(x) acts the same way as foo(x.super) > bar(&x) acts the same way as bar(&x.super) > > i am not quite sure i am getting the answers along the lines of "use > protocol forwarding" instead. i have no protocol to begin with. for a > preexisting value type (e.g. OS provided) > Value subtyping has many uses and is something which will be very powerful, if and when it arrives in Swift. The idea of a reference type that can subtype a value type is intriguing but obviously requires a lot of thought. Certainly, it is something far into the future. However, *even at that time*, I'm quite certain that you will not be able to subtype an OS-provided value type unless it has already been designed for subtyping, just as you are not able to subtype Swift-native reference types unless they are already designed for subtyping. At that time, just as now, the way to accomplish what you wish for would be some sort of forwarding. The difficulty of maintains a third-party protocol for core types should be much alleviated with greater API stability. it would be a nightmare to create and maintain the corresponding protocol. > > Mike > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
