<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="">Please stop saying that this proposal will bring more consideration to the design of libraries. It isn’t true. I haven’t even seen an argument for why it would be true, it is just taken for granted that it is true.<div class=""><br class=""></div><div class="">As I mentioned in another post, this is structurally very different from things like ‘if-let’ and optionals. Optionals force the user to consider their decision <b class="">in the context it is being used</b> (i.e. as you use the optional/value). This proposal, however, does the opposite. The effect of your actions appear in the context of a completely different user. It is like sitting in a room, flipping a light switch wondering “I wonder what this does?”… meanwhile the people downstairs are wondering why their lights keep turning off and on”. </div><div class=""><br class=""></div><div class="">You can try to test for this, but by definition library authors can only test for scenarios that they have thought of. I have often found people surprise me with their use-cases. Relying on the diligence of other programmers is what leads to things like: "You always need to remember to test for zero before using a pointer". Literally the opposite of optionals! It sounds good, but at the end of the day, people are human and they WILL make mistakes. Best to either catch those mistakes in the context where they happen or to mitigate the effect of it. This proposal basically forces you to feel the full effect of other people's mistakes (thinking that it will discourage them from making them in the first place).</div><div class=""><br class=""></div><div class="">Your only real mechanism for feedback is when users of your library complain to you that something that they need isn’t subclass-able. This is the point where most framework authors will actually learn that this feature/default exists. Users of a framework will learn of it slightly earlier, when they find they need to subclass something, and it just isn’t possible.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I would much prefer adding a ‘sealed’ keyword which library authors could use to annotate things which they do not want subclassed outside of the module. Or preferably, as others have suggested, allow augmentation of ‘final’ with ‘public(final)' or ‘internal(final)’.</div><div class=""><br class=""></div><div class="">The only case where I would support ‘sealed’ by default is if there are 3 levels: open, sealed, final. Final would allow 'public(final)' and 'internal(final)’ to allow private subclassing inside the file/module. Sealed would be the same, except it would allow the user to subclass by explicitly acknowledging the risk using ‘unsafe’: “unsafe class MySubclass:SealedSuper“ and “unsafe override func”. Final would not allow the override.</div><div class=""><br class=""></div><div class="">That is the case where ‘sealed’ makes sense as a default…</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class="">P.S. The current proposal will only cause massive problems down the line, IMHO. We will find an escape hatch is needed, but we will have made optimizations based on assumptions of finality which prevent us from easily adding one.</div></body></html>