> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution > <[email protected]> wrote: > >> … >> Additionally, the design allows ‘final’ to take any one of those visibility >> levels as a parameter, to indicate that the type should be treated as >> ‘final’ at and above the specified scope. Thus ‘final(public)’ prevents >> subclassing outside the module, while ‘final(internal)’ prevents it outside >> the ‘private’ scope. For consistency, ‘final(private)’ is also permitted, >> although it means the same thing as ‘final’ by itself. > > I feel final(public) could be confusing given how we currently have > private(get/set). What about public(final)? That’s at least consistent with > current access syntax.
The syntax that most closely aligns with private(set) is internal(inherit). The parameter expresses a capability not a limitation and it is used with an access modifier that specifies the *maximum* access level that is allowed to have this capability. `final` is also misleading in this context because it implies to most people that there are *no* subclasses (inside or outside the module). The only way to express `final` in Swift’s access control system would to have a `never` access modifier allowing you to say `never(inherit)`. I can’ think of any other uses for an access level like this. `final` is much more direct and is the term of art. I don’t see a reason to change the spelling of `final` and parameterizing it doesn’t make any sense - if something is `final` it is `final` in *all* scopes. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
