[swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson]

> On Feb 16, 2017, at 4:55 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Feb 16, 2017, at 5:42 PM, Sean Heber via swift-evolution <swift-evolution at swift.org> wrote:
>> Honestly I really think this should be seriously considered. I do use private and fileprivate and such myself *because it’s there* and as a result it feels like I should - but I shudder to think how much brainpower I’ve wasted(?) on deciding which one to use when. I strongly suspect that the degree of the benefits of all these access levels is not as significant as it seems on the surface.
> 
> I think this applies more to private vs. fileprivate.  Having *some* way to mark something as private — if nothing else, to tell other programmers (including Future You) to think twice before using it directly — is pretty useful in a large project.  But having finer shades than that does seem to just cause mental anguish.

As I have said elsewhere, I think the mental anguish mostly derives from the fact that scoped private is not the right “default” in a language that uses extensions pervasively.  Chris’s suggestion of having private mean “same file *and* same type” would be a good default.  But if we’re not willing to *also* have fileprivate then the Swift 2 definition of private is the best “default’.  

I still think scoped access control is valuable but taking `private` as the keyword for this was a mistake.  I’d like to see us take another stab at identifying a suitable name for it.  That said, I get the feeling that not too many others have appetite for this so it may be a lost cause...

> 
> John.
> 
>> 
>> l8r
>> Sean (who has no actual data)
>> 
>> 
>>> On Feb 16, 2017, at 4:34 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat because this might be controversial here.
>>> 
>>> I think both ‘private’ and ‘fileprivate’ are unnecessary complications that only serve to clutter the language.
>>> 
>>> It would make a lot more sense to just have internal and public only. No private, no fileprivate, no lineprivate, no protected. It’s all silly.
>>> 
>>> Slava
>>> 
>>>> On Feb 15, 2017, at 7:40 AM, T.J. Usiyan via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> "Either keep it or drop it, but don't keep fiddling with it." sums up my position well.
>>>> 
>>>> On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 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
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution