<div style="white-space:pre-wrap">Oops missed sending to the list.</div><br><div class="gmail_quote"><div dir="ltr">---------- Forwarded message ---------<br>From: Shawn Erickson <<a href="mailto:shawnce@gmail.com">shawnce@gmail.com</a>><br>Date: Thu, Jul 21, 2016 at 7:50 AM<br>Subject: Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly<br>To: Tino Heth <<a href="mailto:2th@gmx.de">2th@gmx.de</a>><br></div><br><br><div style="white-space:pre-wrap">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) but it will let them better reason and state their contract which can save effort longer term and improve maintainability.<br><br>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><br>As for the rest let's try to keep the discussion in a proposal thread germane to the proposal and its technical details.</div><div style="white-space:pre-wrap"><br><br>-Shawn<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 21, 2016 at 4:13 AM Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Am 21.07.2016 um 03:41 schrieb Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
><br>
> A class that is closed in 1.0 can be opened in 1.1; a class that is `final` in 1.0 *cannot* be opened in 1.1 (or at least it's a breaking change if it is).<br>
Wait a moment: Aren't "closed", "sealed" and "final" basically all the same as soon as you cross module borders? (but I guess it's just that some words are in wrong order…)<br>
<br>
But anyways, the imho important part is between the parenthesis:<br>
Of course you can rename public properties, mark methods as final, rename all your classes or delete the repository of your library easily.<br>
It might break other peoples code and make them angry, but if this is the driving motivation for SE-0117, the whole proposal is a paradox:<br>
Changing the default for subclassability will break other peoples code on a gigantic scale — not only single methods or classes, but nearly every framework.<br>
<br>
Just imagine this fear of breaking changes had been applied to Swift… do you think it would have been better for the progress of the language?<br>
I don't think so, and I think that libraries aren't that different in this aspect:<br>
When you start something new, you want breaking changes happen as soon as possible, when there is the most tolerance for them.<br>
<br>
As I keep saying for a long time, I think that attitude is an aspect that is terribly neglected here, and imho there are already enough established languages which are pulled down by fear of breaking changes.<br>
Although I have problems sorting out what "swifty" actually means, I might have a longer history as an Apple-customer than most other discussants here, and all marketing aside, there is one distinguishing principle that can be illustrated with many examples:<br>
Better products are preferable over stable products.<br>
<br>
- Tino<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>