I am glad you mention the "protected" scope. For me the private keyword is mostly just frustrating, precisely because I expect it to act in the way you describe "protected" - but it doesn't. This is probably because all of projects at my organisation (regardless of language) have files of about 100-150 lines each, making the distinction between private and fileprivate pretty useless. fileprivate is almost always my go-to, because despite the file length I like to split my types into logical sections via extensions.<br><br>On the other hand, a "protected" scope, exactly how you describe it, would be invaluable! It would allow me to split the definition of, say, a struct or class over multiple files within the same module, providing granulated control over which parts are available to the rest of the module or to the "public". Right now we either have to put everything in one file, which really goes against the grain of our overall structure, or we have to make things that are really just implementation details available as "internal".<br><br>I personally think a "protected" or "type-internal" scope adds a lot more value than two similarly-named "private" scopes. But I recognise that folks who enjoy long files (masochists) will understandably argue the exact opposite. But if it came down to it I'd be happier with just "private", than both it AND "fileprivate".<br><br>Geordie<br><div class="gmail_quote"><div dir="ltr">Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> schrieb am Do. 16. Feb. 2017 um 12:17:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16.02.2017 10:14, Goffredo Marocchi via swift-evolution wrote:<br class="gmail_msg">
> I think it would be a step back as it again oversimplifies access control<br class="gmail_msg">
> IMHO. If we touch access control we should aim to improve it from both a<br class="gmail_msg">
> library implementation point of view but for a user point of view as well.<br class="gmail_msg">
<br class="gmail_msg">
+1. I can't understand the opinion that we must to "simplify" but not<br class="gmail_msg">
"improve". IMO access levels in languages like C# understandable by newbie<br class="gmail_msg">
very well. IMO there is nothing hard(not more than concept of Optional or<br class="gmail_msg">
generic type/protocol programming) to remember/understand 4-5 access<br class="gmail_msg">
levels. Especially, if newbie can start programming even don't know about<br class="gmail_msg">
access levels - as we have "internal" by default.<br class="gmail_msg">
But these access levels adds a real value for the programmer, when he/she<br class="gmail_msg">
can express intention better(even if there is just one coder!) and have<br class="gmail_msg">
compiler support.<br class="gmail_msg">
<br class="gmail_msg">
IMO we need the ability to say "in subtype or in extension in the same<br class="gmail_msg">
*module*". Probably even just as "in the current file and in subtype or in<br class="gmail_msg">
extension in the same *module*". I do think this solves the many questions<br class="gmail_msg">
raised regarding limitations of current access modifiers.<br class="gmail_msg">
<br class="gmail_msg">
Just as a variant:<br class="gmail_msg">
* public -> outside of the module<br class="gmail_msg">
* internal -> inside module<br class="gmail_msg">
* private -> inside file<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">
IMO very clear model. "private" is something that is personal, hidden and<br class="gmail_msg">
locked, nobody should touch this. "protected" - under protection, not for<br class="gmail_msg">
public, but in some situations access can be granted. In this case we have<br class="gmail_msg">
Swift2 simplicity of modifiers plus extra modifier that solves problems<br class="gmail_msg">
with code distribution in files and with sharing implementation details for<br class="gmail_msg">
subtypes/extensions in the same module. As I understand, no impact on ABI<br class="gmail_msg">
as 'protected' just for internals of module. No?<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> Sent from my iPhone<br class="gmail_msg">
><br class="gmail_msg">
> On 16 Feb 2017, at 06:20, Chris Lattner 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">
>> On Feb 14, 2017, at 11:46 PM, Jean-Daniel 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">
>>>>> Keeping with the spirit of Swift and staying consistent with its<br class="gmail_msg">
>>>>> design, I see two plausible meanings for private:<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> Private could mean either:<br class="gmail_msg">
>> ...<br class="gmail_msg">
>>>>> (2) accessible only to the current type/scope and to extensions to<br class="gmail_msg">
>>>>> that type that are in the current file.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> I think (2) is worth discussing. My 2 cents:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> *Pros*<br class="gmail_msg">
>>>> • Solves a high percentage of use cases of *fileprivate*<br class="gmail_msg">
>>>> • Type-scope proponents retain some of the safety<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> *Cons*<br class="gmail_msg">
>>>> • Less straight forward to explain<br class="gmail_msg">
>>>> • Access to different type/scope in same file not possible anymore<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Which means that if we choose 2, we must keep fileprivate.<br class="gmail_msg">
>>> Being able to access other type private members in the same file is an<br class="gmail_msg">
>>> important feature that can’t be easily replaced, so it would badely<br class="gmail_msg">
>>> break existing code if we remove it.<br class="gmail_msg">
>><br class="gmail_msg">
>> Yeah, I think you’re right, which sinks the whole idea: we should aim to<br class="gmail_msg">
>> (re)simplify the access control model. (2) is also problematic because<br class="gmail_msg">
>> it doesn’t allow the private members to be used by other things in the<br class="gmail_msg">
>> same file. E.g. use a private member of Foo in an extension on String.<br class="gmail_msg">
>><br class="gmail_msg">
>> IMO, removing fileprivate and making private match Swift 2 semantics<br class="gmail_msg">
>> seems like the more promising approach.<br class="gmail_msg">
>><br class="gmail_msg">
>> -Chris<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><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>