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 < [email protected]> wrote: > > On 10 Sep 2016, at 14:16, T.J. Usiyan via swift-evolution < > [email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 ([email protected]) > 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 < > [email protected]> 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 ( > [email protected]) 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 > >>> [email protected] > >>> https://lists.swift.org/mailman/listinfo/swift-evolution > >> > >> _______________________________________________ > >> swift-evolution mailing list > >> [email protected] > >> https://lists.swift.org/mailman/listinfo/swift-evolution > >> > >> > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
