[swift-evolution] [Proposal] Sealed classes by default

[Sean Heber]

Coming in late on this, but here’s my take guided by the principal of least surprise (according to me):

- everything is sealed within its module by default, no keyword
- use “public” to mean “exported out of the module, subclass/overridable”
- use “public(final)” to mean “exported out of the module, no subclassing or overriding externally, but overriding and subclasses allowed internally”
- meaning of “final” does not change
- using “public final” then means the same as both public(final) and also “final” internal to the module
- using “public(final) final” could be presented as an error with fixit since it’s redundant

Did I miss anything?

l8r
Sean



> On Jul 1, 2016, at 12:53 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jul 1, 2016, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote:
>> If “opened”, who or what did the opening? If “open” is like “extensible”, then I would interpret “opened” to be like “extended”.
> 
> Yeah, I would prefer "open" to "opened".
> 
> John.
> 
>> 
>>> On Jul 1, 2016, at 10:35 AM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> The proposal was to use "sealed" so why not "opened"? I understand it
>>> may not be common to use "opened" as an adjective but from the
>>> dictionaries I consulted it is possible to.
>>> 
>>> opened class MyViewController: UIViewController {
>>>     opened func displayMe(_ me: person) { … }
>>> }
>>> 
>>> On 1 July 2016 at 13:47, John McCall via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>>> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>> That starts to look an awful lot like a fifth access level just for classes
>>>> (I know you're not proposing one, but it could start to look that way to a
>>>> user). I think there's much to be said for having the word public in front
>>>> of things that are public. Unless, of course, your strawman keyword is a
>>>> much maligned compound word that begins with "public", like
>>>> "publicoverridable".
>>>> 
>>>> 
>>>> I would also prefer a single keyword if the word implies something about
>>>> accessibility.  "open" does that, although using it here would conflict with
>>>> its potential use on enums unless we required all cases within the defining
>>>> module to be present in the enum declaration rather than extensions.
>>>> 
>>>> I don't think we'd ever use a compound keyword that starts with public; we'd
>>>> just separate them and say that the second half can only be present on a
>>>> public declaration, or do this parenthesized syntax.
>>>> 
>>>> John.
>>>> 
>>>> 
>>>> On Fri, Jul 1, 2016 at 01:54 Brent Royal-Gordon <brent at architechies.com>
>>>> wrote:
>>>>> 
>>>>>> If we're going to go along those lines, we should just use
>>>>>> public(subclassable) and public(overridable).  We can fall back on those if
>>>>>> necessary; I would just like to continue looking for better alternatives.
>>>>> 
>>>>> I would prefer to have a *single* keyword which meant both public and
>>>>> overridable. That would minimize the impact of this feature—instead of
>>>>> writing:
>>>>> 
>>>>>      public class MyViewController: UIViewController {
>>>>>              public func displayMe(_ me: person) { … }
>>>>>      }
>>>>> 
>>>>> You'd write (strawman keyword):
>>>>> 
>>>>>      openseason class MyViewController: UIViewController {
>>>>>              openseason func displayMe(_ me: person) { … }
>>>>>      }
>>>>> 
>>>>> And then `MyViewController` could be subclassed, and `displayMe`
>>>>> overridden.
>>>>> 
>>>>> --
>>>>> Brent Royal-Gordon
>>>>> Architechies
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution