[swift-evolution] final + lazy + fileprivate modifiers

[Jose Cheyo Jimenez]

> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 14, 2017, at 3:20 AM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>> 
>> 
>> On 14 Feb 2017, at 09:25, Goffredo Marocchi <panajev at gmail.com <mailto:panajev at gmail.com>> wrote:
>> 
>>> I disagree with that as well as I still think we are damaging the language each time we take a known concept (like access levels) and give new meanings to the same keywords. I still look baffled at the redefinition of do and the addition of repeat for example...
>>> 
>>> Private, the way it was before, was an admittedly curious take on how most languages mean by private and we have jumped through a lot of hoops to justify why we did not start with Java/C++/C# like access control and augmented it instead of redefining things, omitting others, and then constantly pulling the language left and right with not a lot of permanent consensus either way as this discussion and others before show.
>> 
>> It's a curious take, but it is a curious take is perfectly coherent with Swift extensions. How else would you access private implementation details from an extension? But putting it in the same file, instead of having to resort to an internal access level.
> 
> Right.  Swift is its own language distinct from Java/C++/etc.  While it is intentionally designed to remain familiar (and thus reuses many keywords across the language family), it often does so with slightly different meaning / behavior.  Consider ‘throw’ for example.
> 
> 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.

+1 for #2

I think #2 strikes a really good balance and addresses all the uses of file-private for me personally. I don’t think the argument of trying to prevent people from accessing private members or methods in an extension stands specially when those extension live in the same file. If I really want something to be private then I can declare that inside an extension in which case other extension could not reach it. 


// File.swift
struct MyType {
    private func myMethod(){}
}

extension MyType {
    private func myMethodCantBeSeen(){}
    func myExtenMethod1(){
        myMethod() // Okay #2, in Swift 3 this method needs to be fileprivate
    }
}

extension MyType {
    func myExtenMethod2(){
        myMethodCantBeSeen()// inaccessible due to private protection level
    }
}
// end of File.swift



> 
> -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/20170215/bd59ea35/attachment.html>