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

[David Sweeris]

Sent from my iPhone
> On Jul 9, 2016, at 11:29, 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:
>> 
>> 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.

So, let's say I ask you to support subclassing in your library, and you say no. What's to stop from just writing something like this:
  class YesICan {
    var foo: YouCantInheritThis
    // Duplicate `YouCantInheritThis`'s public API by just passing everything through to `foo`
  }

And overloading/extending anything else I need for `YesICan` to, functionally speaking, inherit from `YouCantInheritThis`.

Yes, I know it'd all be the epitome of annoying boilerplate code, but my point is that if someone wants to subclass something of yours, there's really not much you can do to stop them.

(Before anyone mentions it, yes, the same trick can be used to get around `final` and `sealed`, but IIRC the motivations there were to enable certain compiler optimizations, not to prohibit "unauthorized" inheritance.)

- Dave Sweeris