<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 23, 2017 at 10:28 AM 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 18:31, Tony Allevato <span dir="ltr">&lt;<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="m_7164451787897140057gmail-"><div dir="ltr"><br></div></span><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></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>would be:</div><div><br></div><div>foo(x) // same as foo(x.super)  for which it easy to see what&#39;s going on</div><div>bar(&amp;x) // same as bar(&amp;x.super) for which it is easy to see what&#39;s going on</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>all these questions are easily answered if you consider the equivalent manual implementation...</div></div></div></div></blockquote><div><br></div><div>No, they aren&#39;t, because the equivalent manual implementation that uses composition does not permit you to pass an ExtendsStruct to a function that expects a BaseStruct because they&#39;re different types.</div><div><br></div><div>Looking back, I must have missed your earlier message where you said that `C() is S` would be false and you wouldn&#39;t be able to pass C where S is required. Sorry about that. But if that&#39;s true, then you don&#39;t *really* have an inheritance relationship at all. An inheritance relationship specifically *does* mean that `C() is S` if C extends S. If your proposal doesn&#39;t require that, then you effectively have composition that looks syntactically like inheritance, and now you have an inconsistency in the language:</div><div><br></div><div>class C1: C2  ==&gt;  C1() is C2 == true</div><div>class C1: P  ==&gt;  C1() is P == true</div><div>class C1: S  ==&gt;  C1() is S == false?</div><div><br></div><div>Given those statements, I think what you&#39;re asking for could be achieved just as well using protocol forwarding, which makes the composition relationship explicitly visible instead of hiding it in something that it&#39;s not.</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> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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?</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>i don&#39;t control the preexisting value type in general case, so there is no protocol around to hijack.</div><div><br></div><div>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: &quot;i need String / Data / Rect / etc but the one that&#39;s reference type&quot; this device will be for you.</div><div><br></div><div>class ClassString: String {}</div><div>class ClassData: Data {}</div><div>class ClassCGRect: CGRect {}</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Mike<br></div><div><br></div></div></div></div></blockquote></div></div>