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

[Leonardo Pessoa]

Scott, you really got a point here: should this proposal pass, I
believe the final keyword should be removed as it would be already the
default behaviour and thus unnecessary. I don't think this is on the
proposal.

L

On 6 July 2016 at 16:47, Scott James Remnant via swift-evolution
<swift-evolution at swift.org> wrote:
> -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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>