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 < [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
