> On Oct 6, 2017, at 8:01 PM, Tony Allevato <[email protected]> wrote:
>
> At the time SE-0025 was accepted, "private extension" would have been
> meaningless if it did not mean "fileprivate" because it predated the SE-0169
> behavior extending "private" to extensions in the same file. The very issue
> being debated here is whether the oversight that SE-0169 did not consider
> extensions—now that "private extension" *could* have a meaningful use
> separate from "fileprivate extension"—is something that is worth correcting.
>
> If the documentation is out-of-date and needs to be updated to list describe
> unintuitive special behavior, why not use the opportunity to make the
> behavior intuitive and consistent instead?
Lets say you “fix” the private extension override. Now MyClass2.myFunc2() is
not accessible from outside the type.
Wouldn't MyClass2.myFunc2() now be inconsistent with MyClass.myFunc()?
I don’t think you can make a change to one with out causing other
inconsistencies. I rest my case. :)
private class MyClass {
static func myFunc(){ // This would now act differently from private
extensions?
print("acts like fileprivate now")
}
}
private class MyClass2 {}
private extension MyClass2{
static func myFunc2(){
print("Same as MyClass.myFunc")
}
}
MyClass.myFunc() // acts like fileprivate
MyClass2.myFunc2() // The proposed change would hide myFunc2
//Error: 'myFunc2' is inaccessible due to 'private' protection
level
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
