[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jose Cheyo Jimenez]

> On Apr 8, 2017, at 5:19 AM, Neil via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

I really like the idea of partial but it would need to be restricted to the same file. This would allow partial to just be a compile time feature which just zips up a type together.  Another great feature would be that it could allow stored properties because it is only a compile time feature. Partial could be used to communicate to the user that this type has additional members and properties declared somewhere else in the file. 

+1 for file scope partial. 


> - 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" <swift-evolution-bounces at swift.org on behalf of swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170409/25e0a05c/attachment.html>