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

[Shawn Erickson]

I fall more in Matthew side of this regarding sealed by default.
On Sat, Jul 9, 2016 at 12:29 PM Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jul 9, 2016, at 11:04 AM, Tino Heth <2th at gmx.de> wrote:
> >
> >
> >> Of course it can be done either way.  But there are significant
> ecosystem robustness advantages to making sealed the default and
> comparatively few downsides.  Most libraries are open source (so can be
> modified directly or via PR if necessary)
> > First:
> > The claim about robustness sounds like a fact, despite being just an
> opinion (feel free to correct me if you have any evidence at all). We
> should stay honest with our predictions.
> > Second:
> > Do you really believe there will be positive impact on open-source
> libraries?
> > My forecast is that closed by default will dramatically increase trivial
> pull request where developers ask for unsealing so that they can do as they
> like…
>
> I think this is a good thing.  It will force a considered answer and a
> discussion about whether or not subclassing should be supported by the
> library.
>
> > and I've no idea why somebody could come up with the idea that forking
> is desirable.
>
> Forking is desirable if your goals, needs, values, etc are substantially
> different than the library author such that you do not agree on what the
> API contract should look like.
>
>
> _______________________________________________
> 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/20160709/dd98c4f6/attachment.html>