<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jun 22, 2017 at 5:15 PM Mike Kluev &lt;<a href="mailto:mike.kluev@gmail.com">mike.kluev@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On 23 June 2017 at 02:43, Tony Allevato <span dir="ltr">&lt;<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato at gmail.com</a>&gt;</span> wrote:<br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">There&#39;s been talk about &quot;protocol forwarding&quot; that I think would achieve a lot of these goals, without the sharp edges involved trying to define inheritance between a class and a struct. The proposed feature would eliminate the boilerplate you&#39;re talking about.</div><div dir="auto"><br></div><div dir="auto">I&#39;m on my phone so I can&#39;t pull up links to old discussions, but Matthew Johnson is who was pushing it so you may want to look back at what he&#39;s said on the topic.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>thanks, i skimmed through it now and will have a closer look later.</div><div>does it address (2) though? (preexisting value types we can&#39;t change)</div><div><br></div><div>as to the sharp edges: i do not see a single one in the &quot;manual&quot; implementation of this approach and the idea of this proposal is that it is equivalent to the manual implementation...</div></div></div></div></blockquote><div><br></div><div>Imagine something like this:</div><div><br></div><div>struct BaseStruct { ... }</div><div>class ExtendsStruct: BaseStruct { ... }</div><div><br></div><div>func foo(x: BaseStruct) { ... }</div><div>func bar(x: inout BaseStruct) { ... }</div><div><br></div><div>var x = ExtendsStruct(...)</div><div>foo(x)</div><div>bar(&amp;x)</div><div><br></div><div>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?</div><div><br></div><div>Supporting better composition (such as through protocol forwarding) avoids all of these issues.</div><div><br></div><div>Let&#39;s go back to step 1: what&#39;s your use case for wanting inheritance between a class and a struct vs. something like protocol forwarding? You&#39;ve proposed a feature in the abstract but it would be more helpful to know what problem you&#39;re trying to solve. Do you just want to create a new type that contains the same data and methods as a value type, plus others, but as a reference type? Is it important for your use case that there is an &quot;is-a&quot; relationship between the two types, or do you just want to reüse the implementation of the value type? If you do want an &quot;is-a&quot; relationship, how do you get around the fact that the *identity* of the reference type would be lost if you used it polymorphically through the base struct type?</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Mike</div><div><br></div></div></div></div></blockquote></div></div>