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

[John McCall]

> 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 <mailto: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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/bba85d85/attachment.html>