I agreed with Charlie, but I think there’s another option. The access control problems that both SE-0159 and SE-0169 are attempting to address can be resolved not by changing the definition of the existing access modifiers, but refocussing the use of extensions.
One such way would be to introduce a `partial` modifier. It would be similar to C#’s partial modifier. The proposed partial modifier would be purely additive and it would go a long way to mitigate the access control issues inherent in extension-oriented design. The key characteristics of partial-oriented design would be: - Partials would allow the splitting of implementations into multiple logical units without the same-file restriction. - Partial definitions of a type are restricted to same module. If you wish to add functionality to a type external to its defining module, use an extension. - Partials would provide greater clarity between additive extension and the original implementation. - Within a partial, private would be type-private. - Within an extension, private would be scoped-private (the status quo). I do see that the last two points may introduce some friction. Particularly because: - Within a partial, fileprivate would be more restrictive than private. - Within an extension, fileprivate would be less restrictive than private (the status quo). However, I don’t see these as too challenging for educators or developers as they are differentiated by their top-level scope. On 07/04/2017, 05:57, "Charlie Monroe via swift-evolution" <[email protected] on behalf of [email protected]> wrote: > Simply as long as it's file-based, it's not a solution, it's just another attempt to satisfy some part of the community. I'm not saying that the current access levels are perfect, but I still believe the way to go is to either use submodules, and/or introducing the concept of "protected" members. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
