I think I could get behind this. It definitely takes care of the 80%. It might even enable adding storage in extensions *within the submodule*
There is one major use case which I see all of these proposals failing to handle (although that may be intentional for some designs), is where you have something internal to the type, but you still want to allow subclasses/extensions outside the framework (which need that information) to access it. An actual example of this is UIGestureRecognizer. This class is designed to be subclassed outside of the framework, but it hides things like setting the ‘state' from client code (without hiding it from subclasses). This is important, because if a client sets the state directly, then it results in either undefined behavior, or an infinite loop. Other languages use ‘protected’ and ‘friend’ to accomplish this. I am wondering if there is something we can do to solve that in Swift without the complication of protected/friend... Thanks, Jon > On Feb 21, 2017, at 3:40 PM, Nevin Brackett-Rozinsky via swift-evolution > <[email protected]> wrote: > > I think entities declared as “internal” should be visible throughout the > entire *module* just as they are today. In particular, if I write “struct Foo > {}” inside a submodule, then Foo should have internal visibility (the default > when no access level is specified) and thus should be available to the entire > module. > > Similarly, if I write “public struct Bar {}” inside a submodule, then Bar > should be exported from the module and available to client code. In other > words, the submodule should exist to *organize* code, not to change its > meaning. > > Moreover, the ongoing access level discussions elsewhere on the list make > clear that many people believe there should be just one visibility more > restricted than “internal” (which of course should be named “private”). If we > go that route, then “private” would mean “visible in this submodule only”. > For files which are not in a submodule this acts like “fileprivate”, and for > files which *are* in a submodule it means they can share their implementation > details with closely related code (usually types and extensions) while > allowing that code to be in separate files as appropriate. > > That is most of what I want out of submodules: to provide all the benefits of > Swift-2-era “private” without requiring that everything be stuffed inside one > single file. For all other purposes a submodule would be transparent, it just > lets you split up a large file along its natural divisions. Consequently, I > see no need or purpose for nested submodules, because a submodule simply > “acts like” a single file. > > Nevin > _______________________________________________ > 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
