<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jul 8, 2016, at 12:30 PM, Tino Heth <<a href="mailto:2th@gmx.de">2th@gmx.de</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><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). 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></blockquote><div><br></div><div>I didn't say it isn't dramatic, only that it isn't as dramatic a change as some commenters seem to suggest.</div><br><blockquote type="cite"><div><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></blockquote><div><br></div>It's not about guilt or innocence, or any kind of lenience or punishment. <div><br></div><div>It's mostly about whether we want to foster an ecosystem where public API contracts have been explicitly considered or not. There are some ancillary benefits as well but those are much less important.<div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">Defaults matter, because they transmit a message:</div></div></blockquote><div><br></div>I agree.</div><div><br><blockquote type="cite"><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></blockquote><div><br></div><div>In a majority of cases today this openness is better fostered by Github than "anything goes" public API.</div><br><blockquote type="cite"><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></blockquote><div><br></div><div>I really wish Objective-C had this feature from the start. I believe there would have been significant benefits to Apple's platforms and ecosystem. The reasons for believing (or not believing) this have been discussed in depth so there isn't a need to rehash them now.</div><br><blockquote type="cite"><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></div></blockquote><br></div></div><div>Actually open by default has caused some very nontrivial difficulties for Apple's framework maintainers. We all pay the price for this whether we engage in such subclassing and overriding or not. I find that pretty unfortunate, especially for those of us who do find other ways to solve our problems.</div><div><br></div><div>-Matthew</div><div><br></div></body></html>