> On Oct 7, 2017, at 10:17 AM, Nevin Brackett-Rozinsky via swift-evolution
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
