[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