[swift-evolution] final + lazy + fileprivate modifiers

[David Waite]

The primary point of access modifiers is communication, with the secondary point of something like ‘internal’ or ‘final’ to be compiler optimization. Other languages do just fine with just having naming conventions for implementation details, rather than having the compiler enforce that behavior (or even, start having the language itself enforce the naming conventions)

Our justification of access modifiers should be based around communication and compiler optimization, and not completeness against possible options or against features in other languages.

So private and fileprivate serve to communicate that something is an implementation detail of a type, and that manipulation without understanding the type could lead to you (for example) invalidating the type invariants. This IMHO is a useful enough concept to warrant a keyword to communicate.

However, my opinion is that it absolutely *doesn’t* warrant two keywords, and “private” is the less useful of the two due to it blocking extensions.

-DW


> On Feb 16, 2017, at 3: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 <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>> > On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170216/9f60c383/attachment.html>