<div>What you are really asking for is a way of flexibly designating a "unit of code" within a module, for which the general solution is submodules. The objection is that, instead of tackling that issue, these are suggestions to invent ad-hoc units of code (scope + extensions only in the same file, scope + extensions only in the same module, class + extensions only in the same file + subclasses only in the same module), and it is possible to invent arbitrary many of these.</div><div><br></div><div>There is, objectively, an actual minimum number of access modifiers, which is two. Those two are: visible only inside the unit of code, or visible both inside and outside the unit of code. In Swift, those are spelled internal and public. Everything else here is really talking about better or more flexible ways of defining a unit of code.</div><div><br></div><div><br><div class="gmail_quote"><div>On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:<br class="gmail_msg">
><br class="gmail_msg">
>> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution<br class="gmail_msg">
>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> True, what I meant was a wider feedback - let's face it, there are many<br class="gmail_msg">
>> more Swift developers now than 2 years ago.<br class="gmail_msg">
>><br class="gmail_msg">
>> My objection is not to the documentation itself, but to the fact that I'm<br class="gmail_msg">
>> unnecessarily exposing an internal implementation detail to the rest of<br class="gmail_msg">
>> the module. Being able to hide it from the rest IMHO leads to better<br class="gmail_msg">
>> though-through API that is indeed meant to be exposed; whereas exposing<br class="gmail_msg">
>> internal details leads to allowing various quick hacks instead. We know<br class="gmail_msg">
>> these quick hacks very well from the ObjC world by accessing private<br class="gmail_msg">
>> parts of the object via duck typing or setting values via KVO.<br class="gmail_msg">
>><br class="gmail_msg">
>> At least this is my experience with which the less implementation details<br class="gmail_msg">
>> are exposed to the outer world, the better.<br class="gmail_msg">
><br class="gmail_msg">
> I think the fundamental disagreement we’re seeing in this thread is the<br class="gmail_msg">
> meaning of “outer world”; to some, it means “users of your module”. To<br class="gmail_msg">
> others, it also means “other developers on my team who are working on other<br class="gmail_msg">
> files in the module”.<br class="gmail_msg">
><br class="gmail_msg">
> Personally I feel enforced encapsulation of implementation detail to the<br class="gmail_msg">
> latter group is less important than the former, and can be handled by<br class="gmail_msg">
> convention. Whereas other users of your module definitely benefit from<br class="gmail_msg">
> access control and being able to consume a clearly-defined interface.<br class="gmail_msg">
<br class="gmail_msg">
I assume we are discussing access modifiers mainly for the former group,<br class="gmail_msg">
i.e. when we are "inside" the module (even when this module is written by<br class="gmail_msg">
the same one person, and especially when it is written by the group).<br class="gmail_msg">
<br class="gmail_msg">
"handled by convention" - are we talking about something like declaring<br class="gmail_msg">
props and methods as __privateprop , m_privateprop etc and write comments<br class="gmail_msg">
to mark that they should not be used outside of some scope? Is it really<br class="gmail_msg">
Swifty and acceptable for the modern language? Will this help to prevent<br class="gmail_msg">
some mistakes with incorrect access? Is it better than simple and clean<br class="gmail_msg">
schema for access modifiers and compiler's help? I don't understand this.<br class="gmail_msg">
<br class="gmail_msg">
IMO, access modifiers is very known and handy abstraction to distinct<br class="gmail_msg">
levels of access and to structure code many developers knows about and use<br class="gmail_msg">
in other languages.<br class="gmail_msg">
At the end, if one wants to keep all internal - no problems!, you can do<br class="gmail_msg">
this right now, just don't use fileprivate/private/etc.<br class="gmail_msg">
<br class="gmail_msg">
Yes, I agree we need a simple and clean schema, not over-complicated, we<br class="gmail_msg">
need nice&clean keywords, we need a required minimum of access modifiers,<br class="gmail_msg">
not more, and I do believe currently we don't have this minimum.<br class="gmail_msg">
<br class="gmail_msg">
Was already suggested, trying again(I do believe this could be a<br class="gmail_msg">
compromised solution to suit needs of the main part of developers):<br class="gmail_msg">
* (as currently) public/open -> outside of the module<br class="gmail_msg">
* (as currently) internal -> inside module<br class="gmail_msg">
* private -> inside file (instead of fileprivate)<br class="gmail_msg">
* protected(or *other* keyword) -> inside file + subtype&extensions in the<br class="gmail_msg">
*same module*<br class="gmail_msg">
<br class="gmail_msg">
What objections could be made for this?<br class="gmail_msg">
Thank you.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> Slava<br class="gmail_msg">
><br class="gmail_msg">
>><br class="gmail_msg">
>>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a><br class="gmail_msg">
>>> <mailto:<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> That blog post starts out right away to say that it's a response to<br class="gmail_msg">
>>> community feedback. Moreover, the scenario you describe was just as<br class="gmail_msg">
>>> possible in 2014 as it is now. Finally, then as now, it's unclear why<br class="gmail_msg">
>>> you consider documentation to be "not pretty." After all, your reader<br class="gmail_msg">
>>> would need to consult the documentation before using a variable anyway.<br class="gmail_msg">
>>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution<br class="gmail_msg">
>>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> I'm aware of this, but that's fairly a long time ago - before Swift<br class="gmail_msg">
>>> was open source and had community feedback and before Swift was used<br class="gmail_msg">
>>> widely among developers.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> To me, real-world use of the language has shown some flaws of<br class="gmail_msg">
>>> missing a protected access control, mainly having to decide between<br class="gmail_msg">
>>> having a variable internal or cramming all of the class extension<br class="gmail_msg">
>>> into one file, making it a 3KLOC mess. Either solution is not pretty<br class="gmail_msg">
>>> - now I have it split among several files with an internal variable<br class="gmail_msg">
>>> commented as "Do not use, for private use of this class only."<br class="gmail_msg">
>>><br class="gmail_msg">
>>>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez<br class="gmail_msg">
>>>> <<a href="mailto:cheyo@masters3d.com" class="gmail_msg" target="_blank">cheyo@masters3d.com</a> <mailto:<a href="mailto:cheyo@masters3d.com" class="gmail_msg" target="_blank">cheyo@masters3d.com</a>>> wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> <a href="https://developer.apple.com/swift/blog/?id=11" rel="noreferrer" class="gmail_msg" target="_blank">https://developer.apple.com/swift/blog/?id=11</a><br class="gmail_msg">
>>>><br class="gmail_msg">
>>>><br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution<br class="gmail_msg">
>>>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>> wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>>> How about removing fileprivate, getting Swift 2 meaning of private<br class="gmail_msg">
>>>>> (as most people here now suggest) and add additional @protected<br class="gmail_msg">
>>>>> annotation for those who want a more fine-grained solution:<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> @protected private - members accessable only from the<br class="gmail_msg">
>>>>> class/struct/enum/... and their extensions within the file<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> @protected internal - again, but you can access it even from<br class="gmail_msg">
>>>>> extensions and subclasses outside of the file within the entire<br class="gmail_msg">
>>>>> module.<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> @protected public/open - the same as above, but outside the modules.<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> To me, this way most people here will be happy:<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> - those wishing the access control gets simplified - it in fact<br class="gmail_msg">
>>>>> does, you don't need to use @protected, if you don't want to/need to.<br class="gmail_msg">
>>>>> - those who need a fine-grained solution, here it is.<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution<br class="gmail_msg">
>>>>>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>> wrote:<br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>>> Sent from my iPad<br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution<br class="gmail_msg">
>>>>>>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>><br class="gmail_msg">
>>>>>>> wrote:<br class="gmail_msg">
>>>>>>><br class="gmail_msg">
>>>>>>><br class="gmail_msg">
>>>>>>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution<br class="gmail_msg">
>>>>>>>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>><br class="gmail_msg">
>>>>>>>> wrote:<br class="gmail_msg">
>>>>>>>><br class="gmail_msg">
>>>>>>>> While we’re bikeshedding, I’m going to add my two cents. Hold<br class="gmail_msg">
>>>>>>>> on to your hat because this might be controversial here.<br class="gmail_msg">
>>>>>>>><br class="gmail_msg">
>>>>>>>> I think both ‘private’ and ‘fileprivate’ are unnecessary<br class="gmail_msg">
>>>>>>>> complications that only serve to clutter the language.<br class="gmail_msg">
>>>>>>>><br class="gmail_msg">
>>>>>>>> It would make a lot more sense to just have internal and public<br class="gmail_msg">
>>>>>>>> only. No private, no fileprivate, no lineprivate, no protected.<br class="gmail_msg">
>>>>>>>> It’s all silly.<br class="gmail_msg">
>>>>>>><br class="gmail_msg">
>>>>>>> Eh, I've used `private` to keep myself honest in terms of going<br class="gmail_msg">
>>>>>>> through some book-keeping functions instead of directly<br class="gmail_msg">
>>>>>>> accessing a property.<br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>>> This is exactly the kind of thing I like it for and why I hope we<br class="gmail_msg">
>>>>>> might be able to keep scoped access even if it gets a new name<br class="gmail_msg">
>>>>>> that ends up as awkward as fileprivate (allowing private to<br class="gmail_msg">
>>>>>> revert to the Swift 2 meaning).<br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>>>><br class="gmail_msg">
>>>>>>> - Dave Sweeris<br class="gmail_msg">
>>>>>>> _______________________________________________<br class="gmail_msg">
>>>>>>> swift-evolution mailing list<br class="gmail_msg">
>>>>>>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>><br class="gmail_msg">
>>>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
>>>>>><br class="gmail_msg">
>>>>>> _______________________________________________<br class="gmail_msg">
>>>>>> swift-evolution mailing list<br class="gmail_msg">
>>>>>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>><br class="gmail_msg">
>>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> _______________________________________________<br class="gmail_msg">
>>>>> swift-evolution mailing list<br class="gmail_msg">
>>>>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>><br class="gmail_msg">
>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
>>><br class="gmail_msg">
>>> _______________________________________________<br class="gmail_msg">
>>> swift-evolution mailing list<br class="gmail_msg">
>>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>><br class="gmail_msg">
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
>>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-evolution mailing list<br class="gmail_msg">
>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-evolution mailing list<br class="gmail_msg">
> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>