<div dir="ltr">Putting a struct with your common vars in it seems like it wouldn&#39;t work, because now it is a member and the vars aren&#39;t exposed on your object directly, so the outer struct wouldn&#39;t conform to the protocols.<div><br></div><div>My original problem with inheritance is that you can&#39;t correctly adopt a protocol on a base class because protocol extensions that specialize based on Self will use the Self of the base, not of the final class.</div><div><br></div><div>Inheritance is fine if nothing happens in the base classes except declaring the vars required by the protocol. However, any protocol extension functionality picked up might be the wrong code for the final class. The only way I see for it to come out right is that the protocols have to be adopted only by the final class/struct.</div><div><br></div><div>#include was just a first thought of how to deal with the need to duplicate the protocol var declarations. I agree, it&#39;s not a good way to handle the problem.</div><div><br></div><div>Maybe I misunderstood it&#39;s purpose, but it seems the swift team is using GYB/python to do code generation to deal with code duplication to address this problem. That seems even messier to me.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 11, 2017 at 10:29 PM, Jens Alfke <span dir="ltr">&lt;<a href="mailto:jens@mooseyard.com" target="_blank">jens@mooseyard.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Mar 11, 2017, at 10:21 PM, David Sweeris &lt;<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>&gt; wrote:</div><br class="m_8431956054288259172Apple-interchange-newline"><div><div><blockquote type="cite" style="font-family:Alegreya-Regular;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">(I see absolutely nothing wrong with inheritance, and it solves exactly this sort of problem. Yes, structs can’t inherit, but they can contain a common struct as a member, which is quite similar and addresses this issue.)<br></blockquote><br style="font-family:Alegreya-Regular;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Alegreya-Regular;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">That forces you into reference semantics, though.</span><br style="font-family:Alegreya-Regular;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></div></blockquote></div><br></span><div>No it doesn’t. A struct member of a struct is still a value. If you put a common <i>class</i> instance in a struct, that would be reference semantics.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>—Jens</div></font></span></div></blockquote></div><br></div>