<div dir="ltr">Indeed, I find it rather less convenient to write “fileprivate” in many places I previously would use “private”, and unfortunate that I must choose between aggregating many pieces into a single lengthy file or else polluting the module scope with implementation details.<div><br></div><div>I agree with Xiaodi that submodules are a far cleaner design, and I would very much like to replace “fileprivate” with a short word that implies “private to the submodule”. Then by default each file could be its own submodule, and a developer could opt into having more files in a submodule if they so desire.</div><div><br></div><div>Count me as opposed to any sort of “class scoped” access level.</div><div><br></div><div>Nevin</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 10, 2016 at 10:01 AM, Rien 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"><span class="">> On 10 Sep 2016, at 14:16, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I am firmly against this. The 5 levels that we have cover us well and have enough complexity already.<br>
<br>
</span>Agree.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> On Sat, Sep 10, 2016 at 5:23 AM, Tom Bates via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> I agree that classprivate would probably not work, maybe constructprivate? but then you are leaving our enum etc.<br>
> With the `internal(class)` suggestion, if declaring a var such as `internal(set) var name: String?` would this become `internal(class, set) var name: String?`<br>
> 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.<br>
><br>
> 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.<br>
><br>
> Suggestions so far:<br>
> `classprivate`<br>
> `constructprivate`<br>
> `private(instance)`, `private(instance, set)` - problem -> how would this work? `public private(instance, set)`<br>
> `internal(class)`<br>
><br>
> 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.<br>
><br>
><br>
> On Sat, 10 Sep 2016 at 07:09 Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> 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.<br>
><br>
> --<br>
> Adrian Zubarev<br>
> Sent with Airmail<br>
> Am 9. September 2016 um 19:09:12, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>) schrieb:<br>
><br>
>> 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.<br>
>><br>
>><br>
>> On Fri, Sep 9, 2016 at 11:34 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> 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.<br>
>><br>
>> 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)!<br>
>><br>
>><br>
>> --<br>
>> Adrian Zubarev<br>
>> Sent with Airmail<br>
>> Am 9. September 2016 um 17:49:29, Tom Bates via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:<br>
>><br>
>>> There is currently no way of accessing "shared code" from extensions declared outside the base .swift file<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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>
>>> =================<br>
>>> //MyClass+Save.swift<br>
>>> extension MyClass {<br>
>>><br>
>>> public func save() {<br>
>>> self.someFunction()<br>
>>> self.sharedFunction()<br>
>>> }<br>
>>><br>
>>> fileprivate func someFunction() {}<br>
>>> }<br>
>>> =================<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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<br>
>>><br>
>>> Regards,<br>
>>> Tom<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>
>> ______________________________<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>
>><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>
> ______________________________<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>
><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>
______________________________<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>
</div></div></blockquote></div><br></div>