[swift-evolution] Class scoped access level

Sat Sep 10 09:31:46 CDT 2016

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.

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.

Count me as opposed to any sort of “class scoped” access level.

Nevin

On Sat, Sep 10, 2016 at 10:01 AM, Rien via swift-evolution <
swift-evolution at swift.org> wrote:

> > 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
>
> _______________________________________________
> 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/1f163bd1/attachment.html>