[swift-evolution] [Proposal][Discussion] Modular Swift

[Zach Waldowski]

I agree with Nevin’s points in large strokes, but I don’t think large files are the end of the world. I think an important takeaway idea from all the access control threads is that we need not provide facilities in the language to support antipatterns; we should more focus on how to encourage good patterns better.

On the face of it, I’m excited by the proposal; even if this isn’t the answer, we should seek to go down any road that removes fileprivate (and I mean remove - not just a new spelling) but preserves aspect the feature to please whatever it is that people like about that feature.

> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
> 
> This proposal is definitely *not* what I want from a submodule system, because it will exacerbate the problem of developers stuffing large amounts of code into a single file.
> 
> The “fileprivate” keyword already encourages long files, because there is no way to split up related components into separate files while retaining encapsulation. And scope-based “private” is even worse of an offender, because it requires nesting code inside the same *type declaration*, so you can’t even benefit from extensions.
> 
> To my mind, any submodule system for Swift should be designed to relieve the pressure for long files, and make it easy to group tightly related files into a single unit with shared visibility. That way developers can easily organize their code into smaller files while utilizing Swift’s pattern of providing protocol conformances in extensions and keeping implementation details hidden from the rest of the module at large.
> 
> For example, one possible design would enable us to replace both “private” and “fileprivate” with a single new access level—probably spelled “private— which restricts visibility to just the current submodule. That way it provides all the benefits of “fileprivate” (implementation hiding and the ability to use extensions) while also allowing code to be placed in separate files rather than one large file.
> 
> Nevin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution