[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