[swift-evolution] final + lazy + fileprivate modifiers

[Brent Royal-Gordon]

> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Keeping with the spirit of Swift and staying consistent with its design, I see two plausible meanings for private:
> 
> Private could mean either:
> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that type that are in the current file.
> 
> I don’t think we’ve ever evaluated and debated approach #2 systematically.

For what it's worth:

I was opposed to SE-0025, but since I lost, I have tried to use `private` wherever it made sense, rather than fighting with the language.

Sometimes, the change of keyword makes no difference. Other times, it's a hassle, because I have to switch between `private` and `fileprivate` as I redesign things, with little perceived benefit. I'd say the split between these is about 50/50.

On a few occasions, I *have* genuinely appreciated the SE-0025 version of `private`. These involved cases where I wanted to ensure that instance variables were only manipulated in certain ways, using interfaces I had specifically designed to handle them correctly. For instance, I might have two parallel arrays, and I wanted to make sure that I only added or removed elements from both arrays at once. I could do this with `fileprivate` by splitting the type into two files, but it was more convenient to do it in one.

In these cases, switching to #2 would *completely* defeat the purpose of using `private`, because the extensions would be able to directly manipulate the private instance variables. I would no longer gain any benefit at all from `private`. All of my uses would either fall into "makes no difference" or "it's a hassle".

I do not support the idea of changing `private` to mean #2. Doing so would eliminate the few decent use cases I've found for `private`. Either keep it or drop it, but don't keep fiddling with it.

-- 
Brent Royal-Gordon
Architechies