<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-caps: 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="">1. As you point out, the majority of the surface area of idiomatic Swift APIs are unlikely to be impacted (value types, protocols, and final classes). &nbsp;This is very likely to apply to future Swift-native APIs from Apple regardless of the outcome of this proposal.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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="">2. There is no impact on users of Apple's Objective-C APIs (AFAICT).</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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="">In the context of these facts, this proposal is not nearly as dramatic a change as many seem to be suggesting.</div></div></blockquote></div>It is dramatic, and your whole argument is flawed because you miss the imho most important point.<div class="">This is not only a question of "will I be able to override this tiny method of UIView in the future?", but a question of attitude:</div><div class="">When you do away with the rule of lenity and change it to "guilty by default", the direct impact is marginal as well — but it is a drastic change for the society as a whole.</div><div class=""><br class=""></div><div class="">Defaults matter, because they transmit a message:</div><div class="">Every rule and obstacle we add to Swift is a statement that says "we favor bureaucracy over freedom", and this will affect the community evolving around the language.</div><div class=""><div class="">When you use a library in a way that wasn't anticipated by its author, you'll ran into issues occasionally; nonetheless, I think we should struggle for an open ecosystem that encourages others to experiment and fail, rather than to limit their possibilities in a futile attempt to protect them.</div></div><div class=""><br class=""></div><div class="">Everyone should ask himself a simple question:</div><div class="">When was the last time you you thought "I really wish the author of that library had restricted my options to use it"?</div><div class="">As a matter of fact, open by default forces nobody to subclass and override, so it's easy to avoid any problems caused by excessive hacking — closed by default, on the other hand, has impact not only on those who believe in restrictions, but on those who dislike them as well.</div></body></html>