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@swift.org> wrote: > >> On Jul 1, 2016, at 10:51 AM, Michael Ilseman <milse...@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@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@swift.org> wrote: >>>> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu <xiaodi...@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 <br...@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@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution