[swift-evolution] Class scoped access level

[Tom Bates]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160910/0676b243/attachment.html>