[swift-evolution] A Comprehensive Rethink of Access Levels in Swift

[Matthew Johnson]

> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170225/97ba07b0/attachment.html>