On 23 June 2017 at 18:31, Tony Allevato <tony.allev...@gmail.com> wrote:
> > Imagine something like this: > > struct BaseStruct { ... } > class ExtendsStruct: BaseStruct { ... } > > func foo(x: BaseStruct) { ... } > func bar(x: inout BaseStruct) { ... } > > var x = ExtendsStruct(...) > foo(x) > bar(&x) > would be: foo(x) // same as foo(x.super) for which it easy to see what's going on bar(&x) // same as bar(&x.super) for which it is easy to see what's going on > What is the behavior in each of these cases? Do foo and bar get a > value-type slice of x? Is that slice the same memory as is occupied by x, > or is it a copy? When bar mutates its argument, does it modify the same > memory occupied by x? > all these questions are easily answered if you consider the equivalent manual implementation... > Let's go back to step 1: what's your use case for wanting inheritance > between a class and a struct vs. something like protocol forwarding? > i don't control the preexisting value type in general case, so there is no protocol around to hijack. essentially this proposal allows your own or preexisting value type to act as a reference type without having any code or upfront provisions. no more, no less. if you ever had a thought similar to: "i need String / Data / Rect / etc but the one that's reference type" this device will be for you. class ClassString: String {} class ClassData: Data {} class ClassCGRect: CGRect {} Mike
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution