-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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
