Access levels exist for encapsulation. They don’t mean anything unless they 
actually allow you to reason about which code can break if you make a change. 
Given that, here is how each existing access level is useful:

    Public means a change could break any code. 

    Internal means only code in the module can break so you can audit all 
usages in that module and fix as needed.

    File private means only code within the file can break so you only have to 
audit the one file.

    Private means only code within the class or extensions in the same file can 
break so you only have to audit part of that one file.

What would a proposed new access level mean for which code has to be audited 
when making a change?

    If any extension can access something even across modules then that makes 
it the same as public. You can’t make any change without risking breaking a 
client.

    If any extension can access something within the same module then it’s the 
same as internal. You have to audit the whole module.

If your new access level doesn’t make a new bucket for what code to audit then 
it’s not adding any value.

> On Oct 29, 2017, at 8:40 PM, Mike Kluev <mike.kl...@gmail.com> wrote:
> 
>> On 30 October 2017 at 02:54, Adam Kemp <adam.k...@apple.com> wrote:
>> 
>> That was my original point. This is what internal does. We don’t need any 
>> new access levels for extensions. Internal solves these use cases. Code in 
>> the same module can be maintained in lockstep so you can make things 
>> internal as needed for extensions. Anything beyond that is effectively 
>> indistinguishable from public so just call it that. 
>> 
> 
> if I have N big classes,  each split across M files to keep size manageable, 
> do I need to have N different modules if i want to achieve a good separation 
> between classes? (same level of protection that private gives for a class 
> that fits in a single file) i.e. one module per one class?
> 
> Mike
> 
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to