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

[Kevin Lundberg]

On 7/6/2016 1:52 AM, Chris Lattner wrote:

>> On Jul 5, 2016, at 5:54 PM, Kevin Lundberg via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> * What is your evaluation of the proposal?
>>
>> -1 as is. I do not want to be constrained by authors of libraries or
>> frameworks into interacting with a system in only the ways they forsee.
>> By making the default be non-subclassable, if a designer does not put
>> thought into all the ways a class can be used then I as a consumer of
>> the library am penalized.
> Out of curiosity, what is your feeling about “internal” as the default level of access control?  It seems that following your concern to its logical conclusion would lead to a design where all members of a public class would be forced to be public.  After all, the author of a library or framework may not forsee the need to interact with a member that they did not explicitly mark public.
>
> -Chris

I can appreciate this argument, but I would hope that my viewpoint is a
bit more nuanced than that :). To turn the tables a bit, one could argue
that, taken to the proposal's logical conclusion, writable properties
should not be publicly writable for safety's sake. Instead, they should
be required to be explicitly marked as publicly settable if needed as it
should be up to the author of that type to carefully consider how safe
it is for others to mutate the state of their types. Yet today both
sides of a property are given the same access level unless one
explicitly restricts the visibility of it's setter. The current behavior
(of properties specifically, and the access control feature as a whole)
achieves a balance of convenience, power, and safety that I am happy with.

The proposed change however sacrifices too much convenience for a
greater sense of safety and control by default. It's not possible to
accidentally override a method like it is in java or objective-c, so the
proposal won't help people who might accidentally override something. If
a developer tries to override a method or class they probably have a
specific reason in mind for doing so, and taking away the options that
this ability presents, by nature of it being the default behavior,
doesn't sit well with me as it has the potential to take away a good
tool from my toolbox.

I agree that API authors should have the power to restrict this
dimension of a type's usage, but I feel that it should be a conscious
choice to do so.

- Kevin