> On Oct 6, 2017, at 8:01 PM, Tony Allevato <tony.allev...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution