[swift-evolution] Class scoped access level

[T.J. Usiyan]

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