> On Feb 25, 2017, at 1:43 PM, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
>
>> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution
>> <[email protected] <mailto:[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.
hmm… ‘semifinal' for things that are closed outside the submodule?
Thanks,
Jon
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
