> On Jul 6, 2016, at 2:47 PM, Matthew Johnson <[email protected]> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
