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

[Scott James Remnant]

-1

This proposal makes Swift a more confusing language.


Swift already has a mechanism for creating public subclassable classes and non-subclassable classes:

  public class SubclassableParentClass { }

  public final class NonSubclassableParentClass { }

This mechanism also applies to methods, properties, and subscripts:

  public func bar() {}

  public final func foo() {}

The proposal makes no effort to remove this existing syntax.

The very fact that this would be legitimate syntax as a result is a bad omen to me:

  subclassable final class ConfusedParentClass {

    overridable final func quuz() {}

  }

The proposal doesn’t even address what that would do, the obvious answer is “compiler error,” but a better answer would be a language design that didn’t allow for this kind of ambiguity.


Conflating access control and finality is confusing. The proposal actually even goes as far to argue that—“conflates” is a word I took from the proposal—but it’s solution *is* a conflation in of its right, because the only way to explain the results is in terms of both:

classes, methods, properties, and subscripts with access control of `internal`, `file private`, and `private` are overridable by code that can access them, to prevent this add the `final` keyword.
classes with access control of `public` are not overridable by code that can access them, to allow this replace the `public` keyword with the `subclassable` keyword.
methods, properties, and subscripts with access control of `public` are not overridable by code that can access them, to allow this replace the `public` keyword with the `overridable` keyword.

Not only is this complicated, and confusing, it isn’t even consistent: to deny overriding or subclassing you add the same keyword; but to allow overriding or subclassing you replace one keyword with two different ones, depending on which you’re doing.


I agree that the alternative of flipping the default, and replacing `final` with `nonfinal` is also undesirable. One of the nicer features of the Swift language design is that the language is easiest for app developers working within a single module, where it can be assumed that “everyone is an adult.” Breaking this to support the less common case of Public API Designers would be a step backwards; their case is important, but it shouldn’t come at a penalty.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/ccc56c87/attachment.html>