[swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Karl]

> On 15 Jul 2016, at 12:46, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> To sum this all up, the core team is rejecting this proposal and requesting a revision to change the concrete syntax to “public open class Foo” instead of “subclassable class Foo".  
> 
> Minor point, but if we're going with the idea of public open and public final for declaration, is it worth re-raising the idea of bracketed accessibility modifiers? When fileprivate vs private was being discussed I was heavily in favour of private(file), private(scope) and private(module) (plus private(type) if we get that) to avoid polluting the language with more accessibility-specific keywords. This seems like a good time to mention it again, as we're now looking at even more keyword pollution:
> 
> 	public(open)
> 	public(sealed)		// Probably not actually defined, but the default for a plain "public" declaration
> 	public(final)
> 	private(module)	// Replaces internal
> 	private(file)
> 	private(scope)		// Default for plain private
> 
> If we get a private(type) that's seven different keyword combinations for one feature, so I still very much prefer it being reduced to just public/private plus a modifier ;)

I think it makes sense to have it bracketed, but I’m not sure about replacing internal/private/fileprivate.

I’m thinking it should be:

public(open) class XYZ {}
public internal(open) class XYZ {}

Etc

I view it along the same lines as mutability for properties - I.e. “public private(set)”.

In that case, it would make sense to do the same for overridable members. You can only override members of an open class, so it makes sense to just use the “open” name in both places to denote that you may create your own versions of these things. An overriden method “is” an instance of the original method in the same way a derived class “is” an instance of its base class. My overriden “viewDidLoad” or whatever “is” the viewDidLoad for this class.

So to summarise, I think it should look like this (just showing off features, obviously it wouldn’t be okay to have public(open) members in an internal(open) class...):

public internal(open) XYZ {

    public private(set) var nonOverridable : Something
    public(open) var overridable : Something

    public(open) private(set) var getterOverridable : UIColor?   // In this case, the subclass can provide a value in its getter (e.g. backgroundColor) -
                                                                                                  // if it doesn’t (I.e. The type is optional), the base class may have a default value stored. I’m not sure… it’s an awkward one.

    public(open) func overridePointForSubclasses() {
        // Don’t you see so many functions named or documented like this? It’s nice that we’ll have them marked-up explicitly.
    }
}

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160716/933b272b/attachment.html>