<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">5)<span class="Apple-converted-space"> </span><b class="">Prototyping</b>. This should also not influence the decision about what the default is for production code. I would not have a problem with a prototyping environment allowing `inheritable` by default (maybe a Playground mode?). There could even be a tool that migrates the prototype to a real project and adds the `inheritable` annotation where necessary. Regardless of what happens here, the prototyping problem can and should be solved independently of the production language and should not influence the default is used in and impacts production code.</div></div></blockquote></div></blockquote></div><div class="">Now, that offers an easy way out: Just assume that Swift stays in prototype-mode (nothing lasts as long as a prototype) and write that migration tool to annotate each class with final — problem solved, everyone is happy.</div></body></html>