> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
>
>> On Feb 14, 2017, at 3:20 AM, David Hart <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>> On 14 Feb 2017, at 09:25, Goffredo Marocchi <[email protected]
>> <mailto:[email protected]>> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
