[swift-evolution] [Pitch] Let's talk about submodules

[Brent Royal-Gordon]

> On Feb 21, 2017, at 11:11 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

Yeah, that's a use case I've thought about. I *think* that, if extensions in other submodules can add `open` methods, it can be done:

1. Create a submodule (or several) containing `UIGestureRecognizer`'s normal APIs.

2. Create a `UIKit.UIGestureRecognizerSubclass` submodule containing the subclass-only APIs in an extension.

3. In the top-level module, declare the main submodule `@exported open`, and declare `UIKit.UIGestureRecognizerSubclass` `open`.

There are holes in this idea—particularly, the setter on the `state` property—but I *think* you could do something along these lines.

-- 
Brent Royal-Gordon
Architechies