[swift-evolution] Class scoped access level

[Goffredo Marocchi]

I am not fully sure all of this was worth it over protected, private, public... we will see ;).

Sent from my iPhone

> On 10 Sep 2016, at 13: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.
> 
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160910/6f940441/attachment.html>