<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 class=""><br class=""></div><div class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">It seems to me adding such an escape hatch makes the entire point of
the proposal moot.
</pre></blockquote>What was the point of the proposal to you then? This proposal makes several things possible that are not currently possible (or are at least not easy) in Swift. For example, this lets you create subclasses inside your module, but still mark the class as final externally. It also allows you to declare something final without an escape hatch if you so desire.</div><div class=""><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">If I say a class I define is internal or private, you have no business
poking at it from an external module; if I say my class is sealed or
final, you have no business subclassing it from an external module.
Swift provides no escape hatch that exposes internal components of a
module; I don't see why subclassibility requirements should be treated
otherwise.
</pre></blockquote><div class="">You have the option of marking something as final if you want that guarantee to hold. What we are talking about here with ‘sealed’ and the escape hatch is the case where you didn’t actually say anything. You haven’t chosen Open or Final. In this case, subclassing is discouraged, but still allowed (with the caller acknowledging and taking responsibility that the code they are writing is brittle).</div><div class=""><br class=""></div>I have written at length in other posts as to why this is necessary with real world code.<br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">Note that most popular OOP languages provide well-known patterns for
creating sealed but public classes, where only the author is able to
create subclasses. These patterns typically involve hiding class
constructors from external modules. If Swift was changed to support
sealed classes the same way, would you then propose a language feature
to defeat access modifiers?</pre></blockquote><div class="">All I will say is that I avoid using those languages as much as possible. It is a separate topic, but in my opinion/experience languages which encourage too much planning/architecture lead to complicated programming structures (as an effort to work around limitations within the rules) and nothing of worth actually ends up getting accomplished. Give me smalltalk or objC any day.</div></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div></body></html>