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

[Daniel Steinberg]

To highlight your comment below - I would favor “sealed” being available, I’m not sure I would favor it being the default.

Would it help to perhaps split this into two proposals. First, decide on the issue of sealable being available first and syntax for it. If this passes then a second proposal that examines whether it should be the default?

Best,

Daniel

> On Jul 10, 2016, at 8:49 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jul 9, 2016, at 01:44, Goffredo Marocchi <panajev at gmail.com <mailto:panajev at gmail.com>> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 9 Jul 2016, at 05:39, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Of course, Swift doesn’t allow this. If someone outside of the module subclasses ModelBase, there’s no way for them to provide the dynamically-dispatched 'init(context:)’, because they don’t have access to the internal ModelContext.
>> 
>> Shouldn't Swift allow this? Wouldn't it be better if we found a different way to handle this than a brute force "you shall only subclass if I think you should"? Is that really an impossible cause that is worth us going completely the opposite direction of most programming languages?
> 
> There is no way to implement the required initializer from outside the module, because it uses an internal type, so what we’re looking for is that any subclasses from outside the module will never have the required initializer invoked on them. I suppose it would still be safe to allow a subclass from outside the module that did not provide any of its own initializers, but that seems like an even more complicated rule.
> 
> (It’s not sufficient to say that the dynamic initializers would just trap at run-time, because it’s possible that the base class has no public initializers.)
> 
>> 
>> Can you tell me why the onus should not be on you, on library authors, to use final or an equivalent keyword to indicate no subclassing is allowed and thus make this intentional?
>> 
>> I am really not sold on why classes should not be subclassable by default. Not all classes suffer of the problem you mention and for those cases you should be able to express your intention explicitly. I am quite against this being a compiler default.
> 
> I admit that this use case says nothing about whether “sealed” should be the default or just available.
> 
>> I think that security by ignorance, which is what automagically enforced rules tend to produce over time, does have some side effects.
> 
> This isn’t really a security issue; it’s a compiler-aided correctness issue. I’ll go more into that in my other email.
> 
> Jordan
> 
> _______________________________________________
> 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/20160710/8a12dcc4/attachment.html>