# \[Review\] SE-0117: Default classes to be non-subclassable publicly

**URL:** <https://forums.swift.org/t/review-se-0117-default-classes-to-be-non-subclassable-publicly/3284>\
**Category:** Announcements\
**Created:** [July 5, 2016, 11:11pm UTC](https://forums.swift.org/t/review-se-0117-default-classes-to-be-non-subclassable-publicly/3284 "2016-07-05T23:11:17Z")\
**Posts on this page:** 1\
**Showing post:** 74

<div class="post-metadata">

**Author:** ![Kevin\_Lundberg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kevin_lundberg/32/353_2.png) [@Kevin\_Lundberg](https://forums.swift.org/u/Kevin_Lundberg)\
**Post date:** [July 7, 2016, 1:34am UTC](https://forums.swift.org/t/review-se-0117-default-classes-to-be-non-subclassable-publicly/3284/74 "2016-07-07T01:34:49Z")

</div>

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

> **···**
>
> 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@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

---

_[View the full topic](https://forums.swift.org/t/review-se-0117-default-classes-to-be-non-subclassable-publicly/3284)._