> On Feb 21, 2017, at 1:46 AM, Jonathan Hull <[email protected]> wrote: > > >> On Feb 20, 2017, at 6:44 PM, Robert Widmann <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> >>> I would honestly love to see something which just maps modules to >>> folders/groups for simplicity sake. >>> >> >> There is nothing about this scheme that prevents you from organizing your >> code this way. However, modulo that particular method of organization, you >> don’t really gain much as a user of the language by imposing this >> restriction. > > I think the big gain is that users of IDEs would just be able to graphically > organize modules in Xcode. Non-IDE users could use the finder to organize > things into nested folders. This maps pretty well with the way I organize my > code already (others may be different), so it doesn’t add much complexity. >
Xcode today is able to do this with nested classes and structures with the hierarchy navigator. Non-IDE users can use grep or (hopefully) some syntax-aware plugin system to help them find these declarations. Really, again, this is a design pattern and one that can be enforced by linters. If we were to impose this restriction at the language level it ties this proposal down to file system structure and we are explicitly trying to avoid that. > On a side note, I do think that people will quickly want a way to reference a > particular submodule boundary with access modifiers. It may not be part of > this proposal, but it is somewhat inevitable. We should consider that as we > consider this proposal… > Modules are not types, access control makes no sense here. APIs may be exported (or not) across module boundaries, but modules themselves are not arbitrary programming constructs nor do we consider them to carry semantic weight as in some other ML-likes. A public module is no different from a private module if you can import it. A private module is no different from a public one if you cannot. > Thanks, > Jon
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
