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
