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

[Scott James Remnant]

> On Jul 6, 2016, at 2:47 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> This is not true.  Public classes will *not* be “final by default”.  It *will* be possible to subclass them within their declaring module.  If they need to be final they will still need to be marked as such.  
> 
> With that in mind, the your “can override” column (do you really mean “can subclass” here?) is also not correct.  The correct answer is “yes, within the module”.  The fundamental difference for this row is that there are some scopes which can *see* the type without the ability to subclass it.  There is no problem with this, it is *exactly* what we want.  

So would this be more accurate?

  access      | can access    | can subclass/  | final
              |               | override where |
 -------------+---------------+----------------+-------
  open        | all scopes    | all scopes     | Error
  public      | all scopes    | within module  | final
  internal    | within module | within module  | final
  fileprivate | within file   | within file    | final
  private     | within scope  | within scope   | final

> The purpose of this proposal is precisely to give library authors the ability to have more fine grained control over what capabilities their library exposes to users.
> 

I don’t have an issue with the purpose, I have an issue with doing it by conflating access control and finality, and making the language confusing as a result.

Assuming the above table matches your expectation, compare it with the same matrix for the language as it is today:

  access      | can access    | can subclass/  | final
              |               | override where |
 -------------+---------------+----------------+-------
  public      | all scopes    | all scopes     | final
  internal    | within module | within module  | final
  fileprivate | within file   | within file    | final
  private     | within scope  | within scope   | final

The existing table is clean, it’s easy to understand; the two concepts are entirely separate from each other. The access control keyword defines where a class, method, property, or subscript can be accessed from; the `final` keyword defines whether or not it can be subclassed or overridden.


To give you an example of the confusion, here is code made perfectly legal by SE-0025:

  public final class Example {

    overridable func foo() {}

  }

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/0676b61e/attachment.html>