<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=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 21.07.2016 um 13:52 schrieb Shawn Erickson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space: pre-wrap;" class="">Oops missed sending to the list.</div></div></blockquote><div>it's quite easy to hit the wrong button — but actually, the first recipient list was a better fit for the spirit of your motivation ;-)</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><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; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap;" class="">Swift 3 is going to break code - as you say - on gigantic scale already. All developers that switch to Swift 3 will have to upgrade all modules they have and any module developer will have to update their code for Swift 3. Does this potentially add additional work for a module developer? Yes (some will get hit harder then others)</div></div></div></blockquote><div>(hope there's at least general agreement on this…)</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><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; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap;" class="">but it will let them better reason and state their contract which can save effort longer term and improve maintainability.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><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; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap;" class="">Anyway this is about setting up a language and compiler supported way of allowing a module developer to more clearly state the API contract for their module while internally having greater freedom to design things as make sense. The defaults are being picked to favor being explicit about the contract which is a good thing for everyone.<br class=""></div></div></div></blockquote></div>I had an intrinsic motivation for that reply — and this is not to stop SE-0117, which, after all, has already been accepted.<div class="">Driven by the same motivation, I'm answering your message as well:</div><div class="">How can you know that anything is "a good thing for everyone"? I can accept a decision that I consider wrong, but not that it is justified with false assumptions (or even lies — seen all that).</div><div class="">There is a huge group of developers who think that the new defaults are no good thing, but absolutely terrible — and that is something supporters of SE-0117 have to accept, even if such tolerance doesn't fit into their mindset.</div><div class="">I'm not even such a big fan of subclassing, but I wholeheartedly oppose this attitude of "we know what's best for everyone": If anyone had a proof that the decision is superior, he could have saved us a whole big discussion… but there is none, so as I advised to live with sealed-by-default, I advise the other camp to be happy about it and stop fortune-telling.</div><div class=""><br class=""></div><div class="">Tino</div></body></html>