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@swift.org> wrote:
> > > On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
