[swift-evolution] Fwd: [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Shawn Erickson]

Oops missed sending to the list.

---------- Forwarded message ---------
From: Shawn Erickson <shawnce at gmail.com>
Date: Thu, Jul 21, 2016 at 7:50 AM
Subject: Re: [swift-evolution] [swift-evolution-announce] [Review #2]
SE-0117: Default classes to be non-subclassable publicly
To: Tino Heth <2th at gmx.de>


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.

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.

As for the rest let's try to keep the discussion in a proposal thread
germane to the proposal and its technical details.


-Shawn

On Thu, Jul 21, 2016 at 4:13 AM Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > Am 21.07.2016 um 03:41 schrieb Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org>:
> >
> > 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).
> 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…)
>
> But anyways, the imho important part is between the parenthesis:
> Of course you can rename public properties, mark methods as final, rename
> all your classes or delete the repository of your library easily.
> 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:
> Changing the default for subclassability will break other peoples code on
> a gigantic scale — not only single methods or classes, but nearly every
> framework.
>
> 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?
> I don't think so, and I think that libraries aren't that different in this
> aspect:
> When you start something new, you want breaking changes happen as soon as
> possible, when there is the most tolerance for them.
>
> 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.
> 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:
> Better products are preferable over stable products.
>
> - Tino
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/8a5c942d/attachment.html>