[swift-evolution] ability to derive a class from a struct or other value type

Mike Kluev mike.kluev at gmail.com
Fri Jun 23 12:28:53 CDT 2017


On 23 June 2017 at 18:31, Tony Allevato <tony.allevato at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170623/7fe79fc2/attachment.html>


More information about the swift-evolution mailing list