<div dir="ltr">Reading between the line of what T.J has said I can see he is keen to see this become reality!<div><br></div><div>It is very easy to come across examples where the current access level do NOT work well and are inhibiting clean, readable code. Which, in my opinion, when considering any kind of scale is probably the most important thing to be able to maintain, extend and ultimately reduce bugs.</div><div><br></div><div>I agree that the obvious concern would be complexity.</div><div>One solution that would eliminate any extra complexity would be to allow extensions to access all private variables and functions from it's initial declaration. </div><div>This would only be the case when the extension's declaration is within the defining module (prevents people accessing private variables when using submodules)</div><div>To restrict access to extensions of the class you would use the `fileprivate` access control.</div><div>If you want access to a var or func outside the defining module then it has to be public as is the case now.</div><div><br></div><div>Again, this would require no migrations to existing code that I can see.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, 10 Sep 2016 at 13:17 T.J. Usiyan <<a href="mailto:griotspeak@gmail.com">griotspeak@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am firmly against this. The 5 levels that we have cover us well and have enough complexity already.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 10, 2016 at 5:23 AM, Tom Bates via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I agree that classprivate would probably not work, maybe constructprivate? but then you are leaving our enum etc.<br><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;line-height:1.5">With the </span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;line-height:1.5">`internal(class)` suggestion, i</span><span style="line-height:1.5">f declaring a var such as `</span><span style="line-height:1.5">internal(set)</span><span style="line-height:1.5"> </span><span style="line-height:1.5">var</span><span style="line-height:1.5"> name: </span><span style="line-height:1.5">String</span><span style="line-height:1.5">?` would this become `</span><span style="line-height:1.5">internal(class, set)</span><span style="line-height:1.5"><span> </span></span><span style="line-height:1.5">var</span><span style="line-height:1.5"><span> </span>name:<span> </span></span><span style="line-height:1.5">String</span><span style="line-height:1.5">?`</span></div><div>Also there would need to be some kind of compile check either way because if you declared an enum for example outside of a constructor you would not be able to mark it as our new constructor only access level or it would become inaccessible throughout the project.</div><div><br></div><div>Re: submodules, they are indeed overkill for this. As you would need a separate submodule for each class you wanted to do this with and then run the risk of inter coupling lots of different really small submodules.</div><div><br></div><div>Suggestions so far:</div><div>`classprivate`</div><div>`constructprivate`</div><div>`private(instance)`, `private(instance, set)` - problem -> how would this work? `public <span style="line-height:1.5">private(instance, set)`</span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">`internal(class)`</span><br></div><div><br></div><div>Personally I think a name like `classprivate` or `constructprivate`, although not particularly well named would reduce complexities with private setters syntax and keep migrations much simpler.</div><div><br></div>
</div><div><div><br><div class="gmail_quote"><div dir="ltr">On Sat, 10 Sep 2016 at 07:09 Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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"><div>I don't think submodules would solve it nicely. Each module/submodule will require it's own namespace + it feels like an overkill to create submodules for a few types. `internal(xyz)` seems to me like a better solution. And yes this is purely additional and nothing for phase 1.<div></div></div><div><div> <br><div><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> </div></div><div><div><p class="gmail_quote" style="color:#000">Am 9. September 2016 um 19:09:12, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="gmail_quote"><span><div><div></div><div>
<div dir="ltr">Isn't the general solution to this problem
submodules? In any case, seems like it'd be out of scope for Swift
4 phase 1.
<div class="gmail_extra"><br></div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Sep 9, 2016 at 11:34 AM, Adrian
Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>There must be a better solution to this problem, because you
might also extend value types from different files. That would
mean, we'd need `structprivate` `protocolprivate` etc.
<div><br></div>
<div>How about: `internal(class)` etc. ? Or something like
`internal(private)` to rule them all (I don't like the last name,
but something that would rule them all would be nice to
have)!</div>
<div><br>
<br>
<div>
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<div>
<div>
<p class="gmail_quote" style="color:#000">Am 9. September 2016 um
17:49:29, Tom Bates via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</p>
</div>
</div>
<blockquote type="cite" class="gmail_quote"><span></span>
<div><span></span>
<div><span></span></div>
<div><span></span>
<div><span></span>
<div><span></span>
<div dir="ltr"><span></span>
<div><span><span style="line-height:1.5">There is currently no way
of accessing "shared code" from extensions declared outside the
base .swift file</span><br></span></div>
<div><br></div>
<div>I would love to see along side the new fileprivate access
level a classprivate access level that would allow any extension
declared outside of the original .swift file to access these
properties and functions in an attempt to reuse code.</div>
<div><br></div>
an example is below...<br>
<br>
=================<br>
//MyClass.swift<br>
public class MyClass {<br>
<br>
classprivate func sharedFunction() {<br>
self.function1()<br>
self.function2()<br>
}<br>
<br>
fileprivate func function1() {}<br>
fileprivate func function2() {}<br>
}<br>
=================<br>
<br>
<div>=================<br>
<div>//MyClass+Save.swift<br>
extension MyClass {<br>
<br>
public func save() {<br>
self.someFunction()<br>
self.sharedFunction()<br>
}<br>
<br>
fileprivate func someFunction() {}<br>
}
<div>=================<br></div>
<div><br></div>
<div>Currently to achieve anything like this you would have to make
the "core" functions public or internal or write the whole thing in
a single file which as I understand it is not optimal for the
compile speed and can get unmanageable for large classes. This
would allow a more managed file structure and the separation of
related functions from the core declaration.</div>
<div><br></div>
<div>There would be no migration needed I don't think as the impact
on current code would be zero until the developer adopts the new
access level</div>
<div><br></div>
<div>Regards,</div>
<div>Tom</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div>
</div>
</blockquote>
</div>
</div>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div></div></span></blockquote>
</div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</blockquote></div>