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
