[swift-evolution] Fix "private extension" (was "Public Access	Modifier Respected in Type Definition")
    Jose Cheyo Jimenez 
    cheyo at masters3d.com
       
    Sat Oct  7 15:05:22 CDT 2017
    
    
  
> On Oct 7, 2017, at 10:17 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter.
> 
> I would summarize the points on both sides as follows:
> 
> For the change:
> • It is surprising to many people that members of a private extension are implicitly fileprivate.
> • There is currently no way to make an extension whose members default to private.
> 
> Against the change:
> • The proposal is source-breaking.
> • The proposal makes “fileprivate” more common.
> • A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal breaks that symmetry.
> 
Great summary! Thank you. 
> Notable questions:
> • Currently “open” cannot be applied to an extension at all, should we allow it?
> • Might we ever want to allow nested (non-top level) extensions, and if so how should access levels on them work?
This could be a solution that would not be source breaking to the topic at hand. 
extension MyType {
    private extension {
            // “true” private here
        }
}
I think it would be a good idea to limit the nesting with other extensions. Other idea. 
extension { // bag of extensions
    private extension MyType {
            // “true” private here
        }
    fileprivate extension MyType2 {
        // fileprivate  here
}
}
I rather have a comprehensive sub module system than nested extensions though.  :)
> 
> Nevin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
    
    
More information about the swift-evolution
mailing list