[swift-evolution] final + lazy + fileprivate modifiers

[Goffredo Marocchi]

I think it would be a step back as it again oversimplifies access control IMHO. If we touch access control we should aim to improve it from both a library implementation point of view but for a user point of view as well.

Sent from my iPhone

> On 16 Feb 2017, at 06:20, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Feb 14, 2017, at 11:46 PM, Jean-Daniel 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:
> ...
>>>> (2) accessible only to the current type/scope and to extensions to that type that are in the current file.
>>> 
>>> I think (2) is worth discussing. My 2 cents:
>>> 
>>> Pros
>>> • Solves a high percentage of use cases of fileprivate
>>> • Type-scope proponents retain some of the safety
>>> 
>>> Cons
>>> • Less straight forward to explain
>>> • Access to different type/scope in same file not possible anymore
>> 
>> Which means that if we choose 2, we must keep fileprivate.
>> Being able to access other type private members in the same file is an important feature that can’t be easily replaced, so it would badely break existing code if we remove it.
> 
> Yeah, I think you’re right, which sinks the whole idea: we should aim to (re)simplify the access control model.  (2) is also problematic because it doesn’t allow the private members to be used by other things in the same file.  E.g. use a private member of Foo in an extension on String.
> 
> IMO, removing fileprivate and making private match Swift 2 semantics seems like the more promising approach.
> 
> -Chris
> _______________________________________________
> 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/f72250e1/attachment.html>