[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Sean Heber]

> The review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 11. The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 

I posted this somewhere else in another thread, but I still think a slightly different approach to all of the access namings might make more sense:

- everything is “sealed" within its module by default, no keyword for this

- use “export” (formerly “public”) to mean “visible outside of the module, no subclassing or overriding externally, but overriding and subclasses allowed internally unless otherwise restricted”

- use “export(public)” to mean “visible outside of the module, can be subclassed or overridden externally”

- “export final” means that the class/method is also final within its own module

- using “export(public) final” *probably* doesn’t make sense, but would mean overriding/subclasses allowed externally, but not internally

My argument for “export” here is that it is the logical inverse of “import” which is how you get another module’s stuff into your module in the first place.

Then I would want to consider a rename of “internal” to “public” and “fileprivate” to “internal” so the complete list would be:

export - accessible outside of the module
public - accessible anywhere within the module
private - accessible only within the scope 
internal - accessible within the same source file

In this way, there is nice symmetry between import/export, and then again between public/private. The source-file-based grouping of “internal” now has a name that is more unique and not immediately related to the other access keywords, either, which makes sense since it’s on a slightly different axis.

After all of this, the “export(public)” case rational would seem to be logical - you’re saying that the symbol is accessible outside of *this* module and subclassable/overridable within the “public” context of whatever module is importing it - hence using both “export” and “public”.

So anyway, I don’t know if this counts as a -1 vote or not or if this is even coherent, but this is my feedback at the moment. :)

l8r
Sean