[swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")
Jose Cheyo Jimenez
cheyo at masters3d.com
Fri Oct 6 22:44:54 CDT 2017
> On Oct 6, 2017, at 8:01 PM, Tony Allevato <tony.allevato at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171006/ff2030ad/attachment.html>
More information about the swift-evolution
mailing list