[swift-evolution] final + lazy + fileprivate modifiers

[Joanna Carter]

> Let's be clear here: Are you thinking of this exclusively as a feature for override points, or are you asking for a `protected` feature in general?

What I am trying to get across is that the concept of fileprivate, as it stands, is almost a waste of effort, in that it only allows privileged access to otherwise private members within the context of a file.

I am totally for the Swift concept of protocols, structs and extensions but, at present, it is not possible to control the visibility of anything in an extension or a struct other than to either place the extensions in the same file as the type being extended, or make the whole shooting match internal.

> I think that a general `protected` feature is not very compatible with Swift's extension-based approach, but I could imagine a feature specifically for overriding. For example, a class like UIViewController might declare:
> 
> 	open(override) internal func viewDidAppear(_ animated: Bool) { … }
> 	// Or maybe `open internal(call)`? That'd be more like `public internal(set)`…
> 
> And then public subclasses could override `viewDidAppear(_:)`, and those overrides could call `super.viewDidAppear(_:)`, but neither other methods in the subclass nor code outside the subclass could call it.

The problem with 'protected' as a keyword is that it has too many connotations of its use elsewhere for classes only.

I believe what some of us are attempting to propose here is a more 'universal' keyword that conveys the intent of being able to extend access of otherwise private members to (but only to) an 'extending entity'. So :

1. for classes - in subclasses or extensions

2. for structs, enums, etc - in extensions

> Would that fulfill your needs, or are you really looking for type-based access control?

I must admit to being fairly old-school when it comes to access control in preferring type-based access control. Mainly down to my experience with trying to keep inexperienced developers from abusing (privileged) stuff when working in the same module.

In previous posts, I have used the keyword 'extensible' to denote the visibility of a member that fulfils the two definitions I give above.

The benefit of 'extensible' is that it does away with both the perceived need for protected in classes and fileprivate to allow extensions to see otherwise private members of the type they are extending.

I will reiterate my feelings : fileprivate is a kludge. It only really serves to encourage megalithic files in order to get around the lack of something akin to "extensible'

--
Joanna Carter
Carter Consulting