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

[Goffredo Marocchi]

Reposting Károl reply on this list.

On Sat, Jul 9, 2016 at 11:01 PM, Károly Lőrentey <karoly at lorentey.hu> wrote:

>
> > On 2016. Jul 9., at 22:55, Goffredo Marocchi <panajev at gmail.com> wrote:
> >
> > Why have they not "fixed" this issue with Java 6/7/8 if it is bad to
> have the current setup by default? Why C++ x09/x11/x14 is also not making
> everything sealed/unsubclassable by default?
>
> I'd wager a guess that the strong desire not to break source compatibility
> with existing code explains why Java and C++ are stuck forever with
> suboptimal defaults. Some members of this list have a bit of background in
> C++ language design (understatement of the day!); perhaps they know more.
>
> > Is it possible that having library authors use something like a sealed
> keyword or similar is good enough for the default case?
>
> Swift is to be safe by default. I believe open subclassability is a power
> tool that's unsafe without adequate training and thick protective gear;
> therefore, it is useful to require posting yellow/black hazard signs when
> it is in use. Safety first.
>
> "Opting for safety sometimes means Swift will feel strict, but we believe
> that clarity saves time in the long run."
>
> Karoly
> @lorentey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160709/9bfc7bd7/attachment.html>