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@swift.org> wrote: > > >> On Jul 9, 2016, at 01:44, Goffredo Marocchi <pana...@gmail.com >> <mailto:pana...@gmail.com>> wrote: >> >> >> Sent from my iPhone >> >>> On 9 Jul 2016, at 05:39, Jordan Rose via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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@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
