[swift-evolution] Class scoped access level

[Rien]

> On 10 Sep 2016, at 14:16, T.J. Usiyan via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I am firmly against this. The 5 levels that we have cover us well and have enough complexity already.

Agree.



> On Sat, Sep 10, 2016 at 5:23 AM, Tom Bates via swift-evolution <swift-evolution at swift.org> wrote:
> I agree that classprivate would probably not work, maybe constructprivate? but then you are leaving our enum etc.
> 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?`
> 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.
> 
> 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.
> 
> Suggestions so far:
> `classprivate`
> `constructprivate`
> `private(instance)`, `private(instance, set)` - problem -> how would this work? `public private(instance, set)`
> `internal(class)`
> 
> 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.
> 
> 
> On Sat, 10 Sep 2016 at 07:09 Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 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.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> Am 9. September 2016 um 19:09:12, Xiaodi Wu (xiaodi.wu at gmail.com) schrieb:
> 
>> 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.
>> 
>> 
>> On Fri, Sep 9, 2016 at 11:34 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
>> 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.
>> 
>> 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)!
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> Am 9. September 2016 um 17:49:29, Tom Bates via swift-evolution (swift-evolution at swift.org) schrieb:
>> 
>>> There is currently no way of accessing "shared code" from extensions declared outside the base .swift file
>>> 
>>> 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.
>>> 
>>> an example is below...
>>> 
>>> =================
>>> //MyClass.swift
>>> public class MyClass {
>>> 
>>> classprivate func sharedFunction() {
>>>   self.function1()
>>>   self.function2()
>>> }
>>> 
>>> fileprivate func function1() {}
>>> fileprivate func function2() {}
>>> }
>>> =================
>>> 
>>> =================
>>> //MyClass+Save.swift
>>> extension MyClass {
>>> 
>>> public func save() {
>>>   self.someFunction()
>>>   self.sharedFunction()
>>> }
>>> 
>>> fileprivate func someFunction() {}
>>> }
>>> =================
>>> 
>>> 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.
>>> 
>>> 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
>>> 
>>> Regards,
>>> Tom
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution