> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >> * What is your evaluation of the proposal? > > I think it's ultimately a good idea. Being noncommittal about > subclassability/overridability—and thus forbidding it in public scope, but > not making any promises about what the module does internally—is the > alternative that preserves the most freedom for the module, and therefore the > most appropriate default. > > However, I don't like the `subclassable` and `overridable` keywords. They > read like opposites of `final` with no implications for access level; I could > easily imagine somebody marking an internal class `subclassable` assuming > that it merely means it can be subclassed internally, and being very > surprised (or even not noticing!) that the class has been made public. > They're also long and cumbersome; that might be seen as a positive, but I > think it will increase the inevitable backlash against this change. > > I prefer the keyword `open`, which sounds like it could be a statement about > the item's accessibility—and even sounds like it ought to be "more public > than public"—and is short enough that it ought to be difficult to grumble > about the change. It also means that both classes and members use the same > keyword, and gives us a keyword that we can later use to "open" other things > in the language, such as allowing you to extend enums with new cases.
Agreed; I also prefer "open" to having two different long keywords that don't (at least to my ear) imply "public". > I think Kevin Lundberg is right to worry about testability, but I don't think > that has to prevent this change. Instead, we should permit `@testable` > imports to subclass/override things that are not publicly > subclassable/overridable, and thus a module built with "Enable Testability" > on can't actually assume there are no subclasses/overrides of `internal` > classes/members even if it doesn't see any. This will block optimizations in > debug builds, but not in release builds. The proposal should be edited to > explain this `@testable` behavior. IIUC the basic design of @testable is to treat the tests for the testable thing as existing within its module, so I think this just falls out. I agree that it should be spelled out in the proposal, though. John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
