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@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@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