<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">I am not fully sure all of this was worth it over protected, private, public... we will see ;).</div><br>Sent from my iPhone</div><div><br>On 10 Sep 2016, at 13:16, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><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 class="HOEnZb"><div class="h5"><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>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div>
</div>
</blockquote>
</div>
</div>
<br>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div></div></span></blockquote>
</div></div>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>