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

[Goffredo Marocchi]

Is it more unreasonable to ask developers to seal their modules or users to unseal them? I would say Apple or third parties shipping frameworks could be asked to think about subclass ability before shipping their commercial library.

Sent from my iPhone

> On 11 Jul 2016, at 07:36, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Resent for Swift Evolution:
> 
> With the existence of Swift on the server, dynamically linked, independently distributed frameworks will not be an Apple-only issue - this extends beyond Apple's OS X-based platforms towards how dynamic frameworks link against each other as if they are to be distributed separately.
> 
> It is short sighted to suggest that all Swift deployments will be under Apple's control.
> 
> On 11 Jul. 2016, at 3:43 pm, Tino Heth <2th at gmx.de> wrote:
> 
>>> It is *not* the case with a framework. Dynamically linked frameworks can be changed without the app even being changed. Imagine if Apple changed UIKit and make UINavigationController final retroactively. 
>> Your argument is true, and you choose a good example — but it's actually the only one that exists at all:
>> There are no other parties that ship frameworks that way, and I don't think this should change.
>> 
>> So the benefits of this proposal would exist for Apple alone, and I can understand why sealed is convenient for an UIKit-engineer.
>> It is tempting to aim for the easiest solution, but it is smarter to take the route that's better for the customer (and we happen to be the customers).
>> And, as others pointed out before, Cupertino is free to diverge from the defaults in either direction, so it is only a little effort to have "sealed by default" without the bad side effects.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution