<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="">To highlight your comment below - I would favor “sealed” being available, I’m not sure I would favor it being the default.<div class=""><br class=""></div><div class="">Would it help to perhaps split this into two proposals. First, decide on the issue of sealable being available first and syntax for it. If this passes then a second proposal that examines whether it should be the default?</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Daniel</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 10, 2016, at 8:49 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 9, 2016, at 01:44, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">Sent from my iPhone<br class=""><br class=""><blockquote type="cite" class="">On 9 Jul 2016, at 05:39, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Of course, Swift doesn’t allow this. If someone outside of the module subclasses ModelBase, there’s no way for them to provide the dynamically-dispatched 'init(context:)’, because they don’t have access to the internal ModelContext.<br class=""></blockquote><br class="">Shouldn't Swift allow this? Wouldn't it be better if we found a different way to handle this than a brute force "you shall only subclass if I think you should"? Is that really an impossible cause that is worth us going completely the opposite direction of most programming languages?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">There is no way to implement the required initializer from outside the module, because it uses an internal type, so what we’re looking for is that any subclasses from outside the module will never have the required initializer invoked on them. I suppose it would still be safe to allow a subclass from outside the module that did not provide any of its own initializers, but that seems like an even more complicated rule.</div><div class=""><br class=""></div><div class="">(It’s not sufficient to say that the dynamic initializers would just trap at run-time, because it’s possible that the base class has <i class="">no</i> public initializers.)</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Can you tell me why the onus should not be on you, on library authors, to use final or an equivalent keyword to indicate no subclassing is allowed and thus make this intentional?<br class=""><br class="">I am really not sold on why classes should not be subclassable by default. Not all classes suffer of the problem you mention and for those cases you should be able to express your intention explicitly. I am quite against this being a compiler default.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I admit that this use case says nothing about whether “sealed” should be the default or just available.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I think that security by ignorance, which is what automagically enforced rules tend to produce over time, does have some side effects.</div></div></blockquote><br class=""></div><div class="">This isn’t really a security issue; it’s a compiler-aided correctness issue. I’ll go more into that in my other email.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>