<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><br class=""><blockquote type="cite" class=""><div class=""><div 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;" class="">I think it's best to keep this thread focused on classes. &nbsp;We can start a new thread for methods later if desired. &nbsp;But we should wait until the dust has settled on the classes conversation IMO.</div></div></blockquote></div>I disagree: The whole thread is not about practical implications but rather about general standpoints, so the discussion will be identical — and I foresee that this second thread would start with "now that we made classes final by default, it's just natural consequence to do the same with methods".<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Making `final` the default, or `sealed` the default, encourages the use of closed class hierarchies. It attempts to make inflexibility the preferred form of shared Swift code. I'm not sure that's the right thing to do.<br class=""><br class=""></blockquote>I don't agree with this framing. &nbsp;IMO it encourages alternative designs emphasizing protocols and composition. &nbsp;This is a very good thing IMHO. &nbsp;I like to think of inheritance is a tool is last resort.&nbsp;<br class=""></blockquote><br class=""></div><div class="">The claim about inflexibility is to take with a grain of salt, but why do you think it is good to force your opinion on how flexibility should be achieved on others? Protocols and composition are useful without breaking inheritance, just leave the choice to the people.</div></body></html>