<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I like the idea of repurposing brackets after private to do this. I think though that it might be better if there were also a private(type) option to allow us to be explicit about it, even if we can still type just private to use it by default.</div><div class=""><br class=""></div><div class="">About replacing private(set), the examples you’ve given look like computed properties, and being able to put the accessibility declaration before the setter is a good option, but for stored properties I think we also need a way to specify the restriction, for example private(file: set) to enable setting the value only at the file level. This means that private on its own is by default actually private(type: get set)</div><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Mar 2016, at 06:49, Patrick Pijnappel via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div style="margin: 0px; line-height: normal; color: rgb(69, 69, 69);" class=""><font face="arial, helvetica, sans-serif" class="">Ok to summarize:</font></div><div style="margin: 0px; line-height: normal; color: rgb(69, 69, 69);" class=""><br class=""></div><div style="margin: 0px; line-height: normal; color: rgb(69, 69, 69);" class=""><b class="">Setter access modifiers</b></div><div style="margin: 0px; line-height: normal; color: rgb(69, 69, 69);" class=""><font face="monospace, monospace" class="">var foo: Int { private set { ... } }</font></div><div style="margin: 0px; line-height: normal; color: rgb(69, 69, 69);" class=""><font face="monospace, monospace" class="">var foo: Int { private set }</font></div>
<ul class="">
<li style="margin:0px;line-height:normal;color:rgb(69,69,69)" class=""><font face="arial, helvetica, sans-serif" class="">Consistent with&nbsp;</font><font face="monospace, monospace" class="">mutating set { ... }</font><font face="arial, helvetica, sans-serif" class="">. Arguably the current&nbsp;</font><font face="monospace, monospace" class="">private(set)</font><font face="arial, helvetica, sans-serif" class=""> is inconsistent.</font></li>
<li style="margin:0px;line-height:normal;color:rgb(69,69,69)" class=""><font face="arial, helvetica, sans-serif" class="">Eliminates the odd corner case of having a double access modifier, e.g. </font><font face="monospace, monospace" class="">public private(set) var foo: Int</font><font face="arial, helvetica, sans-serif" class="">.</font></li>
<li style="margin:0px;line-height:normal;color:rgb(69,69,69)" class=""><font face="arial, helvetica, sans-serif" class="">It's very sensible for custom getters/setters (top case), it just requires allowing a bodiless get/set. We already kinda do this in protocols.</font></li></ul><div class=""><font color="#454545" face="arial, helvetica, sans-serif" class=""><br class=""></font></div><div class=""><font color="#454545" face="arial, helvetica, sans-serif" class=""><b class="">Access modifier keywords</b></font></div><div style="margin: 0px; line-height: normal; color: rgb(69, 69, 69);" class=""><span style="font-family:monospace,monospace" class="">public/</span><span style="font-family:monospace,monospace" class="">private(module)/</span><span style="font-family:monospace,monospace" class="">private(file)/</span><span style="font-family:monospace,monospace" class="">private</span><br class=""></div>
<ul class="">
<li style="margin:0px;line-height:normal;color:rgb(69,69,69)" class=""><font face="arial, helvetica, sans-serif" class="">It's not clear from the keywords how restrictive&nbsp;</font><font face="monospace, monospace" class="">local/private/internal</font><font face="arial, helvetica, sans-serif" class=""> are, while </font><font face="monospace, monospace" class="">private(module)</font><font face="arial, helvetica, sans-serif" class=""> and </font><font face="monospace, monospace" class="">private(file)</font><font face="arial, helvetica, sans-serif" class=""> are obvious. This makes a</font><font face="arial, helvetica, sans-serif" class="">&nbsp;declaration either&nbsp;</font><font face="monospace, monospace" class="">public</font><font face="arial, helvetica, sans-serif" class="">, or </font><font face="monospace, monospace" class="">private</font><font face="arial, helvetica, sans-serif" class="">&nbsp;to a certain scope. Arguably e.g.&nbsp;</font><font face="monospace, monospace" class="">public/module/file/declaration</font><font face="arial, helvetica, sans-serif" class="">&nbsp;has similar benefits but they aren't as clearly access control related as a keyword (e.g. </font><font face="monospace, monospace" class="">module</font><font face="arial, helvetica, sans-serif" class=""> could just as well be declaring a module).</font></li>
<li style="margin:0px;line-height:normal;color:rgb(69,69,69)" class=""><font face="monospace, monospace" class="">private(module)</font><font face="arial, helvetica, sans-serif" class=""> and </font><font face="monospace, monospace" class="">private(file)</font><font face="arial, helvetica, sans-serif" class=""> are relatively long, but the longest –&nbsp;</font><font face="monospace, monospace" class="">private(module)</font><font face="arial, helvetica, sans-serif" class="">&nbsp;– is rarely used (outside the standard library) as it's the default. Most uses of the old </font><font face="monospace, monospace" class="">private</font><font face="arial, helvetica, sans-serif" class=""> are more appropriately done using the new </font><font face="monospace, monospace" class="">private</font><font face="arial, helvetica, sans-serif" class="">, so </font><font face="monospace, monospace" class="">private(file)</font><font face="arial, helvetica, sans-serif" class=""> would likely be used less than </font><font face="monospace, monospace" class="">private</font><font face="arial, helvetica, sans-serif" class="">.&nbsp;</font></li>
<li style="margin:0px;line-height:normal;color:rgb(69,69,69)" class=""><font face="arial, helvetica, sans-serif" class="">The scheme expands very well to named submodules, e.g. if you have a submodule named </font><font face="monospace, monospace" class="">model</font><font face="arial, helvetica, sans-serif" class="">&nbsp;</font><font face="arial, helvetica, sans-serif" class="">you might limit the scope using </font><font face="monospace, monospace" class="">private(model)</font><font face="arial, helvetica, sans-serif" class="">.&nbsp;</font></li><li style="margin:0px;line-height:normal;color:rgb(69,69,69)" class=""><font face="monospace, monospace" class="">private(file)</font><font face="arial, helvetica, sans-serif" class=""> as opposed to </font><font face="monospace, monospace" class="">private-file</font><font face="arial, helvetica, sans-serif" class=""> or </font><font face="monospace, monospace" class="">private/file</font><font face="arial, helvetica, sans-serif" class="">&nbsp;makes it more consistent with the new function-like syntax for e.g. attributes.</font></li>
</ul></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Mar 16, 2016 at 11:26 AM, Ross O'Brien via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">It's occurring to me, reading these recent posts, that we have two orthogonal systems of access levels.<div class=""><br class=""></div><div class="">Swift's current access system is file based; a project file decides which files comprise a module, and the terms 'public', 'internal' and 'private' determine whether a property is accessible to all, accessible only within files of the module, or accessible only within a file. (This takes on an extra dimension as files may belong to several modules).<div class=""><br class=""></div><div class="">The concept which began this discussion, and several of the proposed concepts in this discussion, ask instead for a type-based access system similar to those in other languages including Objective-C, where 'public', 'protected' and 'private' are the terms of choice and they restrict access to a type or subtypes.</div><div class=""><br class=""></div><div class="">I think it would be confusing if Swift applied 'public' to a concept in the file-based access system and 'private' to a concept in the type-based access system.</div><div class=""><br class=""></div><div class="">I would prefer clearer terms which actually mention the restrictions of the level. For example, 'inherited', not 'protected', in the case of properties accessible by a class and its subclasses; 'declaration', rather than 'private' or 'scoped', to refer to properties only accessible within a given type or extension declaration.</div><div class=""><br class=""></div><div class="">Since, at the moment, a declaration can only occur within one file, I think this most-restricted level has managed to pass as a level of the file-based access system. However, if the system is ever extended, we're going to run into new syntax decisions where we have 'private module' functions (accessible only within the given type in the same module) trying to communicate with 'protected file' properties (accessible only with the type and its subtypes in the same file), and that might lead to conflicts, so perhaps we should decide how those might be declared now.</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Mar 15, 2016 at 11:51 PM, Jonathan Hull via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><div class=""><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)" class=""><pre style="white-space:pre-wrap" class="">On Tue, Mar 15, 2016 at 2:33 PM Erica Sadun &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">erica at ericasadun.com</a>&gt; wrote:</pre><div class=""><blockquote type="cite" class=""><pre style="white-space:pre-wrap" class="">And again, moving the access control modification to the end just doesn't look 
right to me or seem to enhance readability. :(</pre></blockquote></div></pre></div></span>I like Shawn’s proposal better for cases where there are custom getter/setter implementations.&nbsp; We should definitely be able to do:<div class=""><br class=""></div><div class="">var foo:Int {</div><div class=""><span style="white-space:pre-wrap" class="">        </span>public get {…}</div><div class=""><span style="white-space:pre-wrap" class="">        </span>private(file) set {…}</div><div class="">}</div><div class=""><br class=""></div><div class="">In fact, that is what I first tried to do before learning about private(set).&nbsp; But without the implementations, it just seems strange to put the scoping after the rest of the declaration (they work above because they are <i class="">before</i> the custom getter/setter).</div><div class=""><br class=""></div><div class="">I still like the idea of having the option to use parameter-like syntax for cases where you don’t have custom getters/setters:</div><div class=""><br class=""></div><div class="">private var foo:Int</div><div class="">private(file) var foo:Int</div><div class="">private(set: file) var foo:Int</div><div class="">private(get: global, set: file) var foo:Int</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I guess, if we had some way to represent the standard getter/setter, that might work too.&nbsp; I don’t love it, but maybe with better wording?</div><div class=""><br class=""></div><div class="">var foo:Int{</div><div class=""><span style="white-space:pre-wrap" class="">        </span>public get useDefault</div><div class=""><span style="white-space:pre-wrap" class="">        </span>private(file) set {…}</div><div class="">}</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 14, 2016, at 10:22 PM, Patrick Pijnappel &lt;<a href="mailto:patrickpijnappel@gmail.com" target="_blank" class="">patrickpijnappel@gmail.com</a>&gt; wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I like Shawn's proposal:&nbsp;</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">&nbsp;</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font face="monospace, monospace" class="">var foo: Int { private(file) set }</font>&nbsp;</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font face="monospace, monospace" class=""><br class=""></font><font face="arial, helvetica, sans-serif" class="">In fact it's probably more sensible than the current private(set) IMO.</font></blockquote></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""><br class=""></font></div><div style="font-size:13px" class=""><font face="arial, helvetica, sans-serif" class="">For example, we already use</font></div><div style="font-size:13px" class=""><span style="font-family:arial,helvetica,sans-serif" class=""><br class=""></span></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">var foo: Int { mutating get { ... } }<br class=""></font></div><div style="font-size:13px" class=""><span style="font-family:arial,helvetica,sans-serif" class=""><br class=""></span></div><div style="font-size:13px" class=""><span style="font-family:arial,helvetica,sans-serif" class="">and not</span><br class=""></div><div style="font-size:13px" class=""><span style="font-family:arial,helvetica,sans-serif" class=""><br class=""></span></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">mutating(get) var foo: Int { get { ... } }<br class=""></font></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Mar 15, 2016 at 4:13 PM, Patrick Pijnappel <span dir="ltr" class="">&lt;<a href="mailto:patrickpijnappel@gmail.com" target="_blank" class="">patrickpijnappel@gmail.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div style="font-size:13px" class="">I like Shawn's proposal:</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">var foo: Int { private(file) set }</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""><br class=""></font></div><div style="font-size:13px" class=""><font face="arial, helvetica, sans-serif" class="">In fact it's probably more sensible than the current private(set) IMO.</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""><br class=""></font></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">While I like <font face="monospace, monospace" class="">private(get: file, set: module)</font>&nbsp;idea, I think it just gets too inconsistent with&nbsp;<span style="font-family:monospace,monospace" class="">private(set: public)</span><font face="arial, helvetica, sans-serif" class=""> and</font><span style="font-family:monospace,monospace" class="">&nbsp;</span><span style="font-family:monospace,monospace" class="">private(set: private)</span><font face="arial, helvetica, sans-serif" class="">&nbsp;(?!)</font></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="">On Tue, Mar 15, 2016 at 3:39 PM, Jonathan Hull via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class=""><div style="word-wrap:break-word" class=""><span class=""><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)" class=""><i class="">On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">swift-evolution at swift.org</a>&gt; wrote:</i></pre></span><blockquote type="cite" class=""><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)" class="">The only question is (as Sean mentioned) how this combines with the syntax
for setter access level, e.g. the current private(set). Options:
- Unnamed 2nd argument, giving private(file), private(file, set),
private(set).
- Named 2nd argument, giving e.g. private(file), private(file, accessor:
set), private(accessor: set). Less ambiguity but longer.
- Not using multiple arguments, but that'd probably break consistency with
the other unification efforts going on to make everything look like
function calls.</pre></blockquote><div class="">What about the following 3 forms?</div><div class=""><br class=""></div><div class="">private(file) //both setter and getter have file scope</div><div class="">private(set: file) //setter has file scope.&nbsp; Equivalent to current “private(set)"</div><div class="">private(get: module, set: file) //getter has module scope &amp; setter has file scope</div><div class=""><br class=""></div><div class="">It is a bit weird, but we should probably also allow “public" in that last form: private(get: public, set: module)</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div></div><br class=""></div></div><span class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></span></blockquote></div><br class=""></div>
</blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></div></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>