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

[Russ Bishop]

> On Jul 5, 2016, at 4:11 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 11. The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> 	* What is your evaluation of the proposal?

I think the goals are laudable but a -1 to the proposal as written. It conflates different things and magically having different behavior inside and outside the module. It seems to add a higher cognitive burden than is really necessary… I imagine trying to explain the behavior to a Swift newcomer and it never being clear on the first attempt. Subclassability is a separate concern from visibility, plus final doesn’t cleanly compose with this design.

IMHO It makes no sense to have a member that is public, non-virtual to external consumers, but overridable to internal consumers. If that’s the case, why not just use a protocol to completely hide the type? It just doesn’t seem like a common case to me.


> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yes

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

C# makes members non-virtual by default, so visibility naturally controls who can see the type and virtual controls subclassing/overriding. Of course C# has protected, which controls visibility to subclassers so you can mark things as internal protected virtual, then the overall type as public virtual. Someone can still subclass but it doesn’t matter because they can’t override anything as all the protected override points are internal… not that it was very common!

When you’re designing things for easy subclassing I found it much more useful to offer protected members as the override points without letting subclassers override the public interface. Much less opportunity for them to screw things up, forget to call super, etc. In the rare case where I wanted to allow them to skip super’s implementation I just added that as a parameter to the protected member.


Russ