+1<br><br>On Monday, 21 March 2016, Tino Heth via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; 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"><div>Many languages which adopt the concept of value types don&#39;t allow subclassing for those, and so does Swift.</div><div>Inheritance for structs is more complex than inheritance for classes, but the &quot;final&quot; limitation isn&#39;t the only possible solution, and Dave Abrahams told me in another thread that changing this rule might be considered in the future — so I&#39;ll risk getting taunted by the cool kids who are in favor of eliminating all ancient OOP-ideas ;-) and start a discussion.</div><div><br></div><div>I guess most readers know about the low-level problems that arise when we switch from pointers (always the same size) to value types (size may vary), so I&#39;ll start with two possibilities for struct subtyping:</div><div><br></div><div><u style="font-size:14px">newtype</u> (see <a href="https://www.haskell.org/tutorial/moretypes.html" target="_blank">https://www.haskell.org/tutorial/moretypes.html</a> — or just read on if you are scared by Haskell ;-)</div><div><br></div><div>When a subtype does not add any stored properties to its superclass (memory layout doesn&#39;t change), there is no difference at the level of object code — only the type checker may stop you from using those two types interchangeably.</div><div>Some use cases:</div><div>- In Cocoa, there is no separate class for (file system) paths; instead, there are some additions to NSString. String doesn&#39;t have those abilities, and imho methods like &quot;<span style="color:rgb(61,29,129);font-family:Menlo;font-size:11px">stringByAppendingPathExtension&quot; </span>deserve a separate Path-struct, so that those special methods don&#39;t pollute the method list of String (URL is the future, so that example is somewhat out-of date).</div><div>- You could impose incompatibility on numeric types to ensure that your calculations use correct quantities. Although this can be annoying (Float vs. CGFloat), decorating numbers with quantity/unit could eliminate bugs that had really disastrous consequences in the past.</div><div>- Increased comfort for floating-point math:</div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="color:#bb2ca2">struct</span> CustomDouble: Double</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><br></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(79,129,135)"><span style="color:#bb2ca2">func</span><span style="color:#000000"> == (a: </span>CustomDouble<span style="color:#000000">, b: </span>CustomDouble<span style="color:#000000">) -&gt; </span><span style="color:#703daa">Bool</span><span style="color:#000000"> {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="white-space:pre-wrap">        </span><span style="color:#bb2ca2">return</span> <span style="color:#3d1d81">abs</span>(a.<span style="color:#4f8187">value</span> - b.<span style="color:#4f8187">value</span>) &lt; <span style="color:#272ad8">0.01</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">}</div></div><div>(no need to specify tolerance for each comparison)</div><div><br></div><div><span style="font-size:14px"><u>Full subtyping</u></span></div><div><br></div><div>As long as you don&#39;t cross module borders, it wouldn&#39;t be that complicated to add inheritance without restrictions.</div><div>imagine you have a &quot;Customer&quot;-type and a &quot;Employee&quot;-type to store personal data (name, address…).</div><div>Those data objects are perfect candidates to be implemented as structs, but they also cry for a &quot;Person&quot;-superclass, so you are forced to either duplicate code, or to implement your objects as reference types.</div><div><br></div><div>In a real proposal, I would include more details on the problems caused by this feature, but I&#39;d like to see some feedback first.</div><div><br></div><div>Best regards,</div><div>Tino</div></div></blockquote><br><br>-- <br>-- Howard.<br>