> On Jun 22, 2016, at 13:05, Matthew Johnson <[email protected]> wrote: > > >> On Jun 22, 2016, at 12:59 PM, Jordan Rose <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> I would really like to see submodules, but I think there would still be >>> valid uses for `fileprivate` even with them. But of course we would need >>> to know the details of submodules to have a good discussion about that so >>> it’s a topic for the future. :) >>> >>> I wonder what became of this: >>> https://github.com/apple/swift/blob/master/docs/Modules.rst#id18 >>> <https://github.com/apple/swift/blob/master/docs/Modules.rst#id18> >> As the author of that document, it became clear (or maybe “it became murky”) >> that everyone wants different things from submodules, both for compiling >> their own targets and for importing other people’s targets. I’d almost >> suggest avoiding the word if you want to propose any of myriad features >> related to them: > > Interesting. The reason I like the idea of submodules is because I think > they could accomplish several of these goals with a single feature in a more > elegant manner and without introducing nearly as much complexity as would > likely be present with independent features. > >> >> - importing a subset of APIs >> - having APIs not imported by default with the top-level module > > Aren’t these kind of duals of each other (subsets of APIs being submodules, > possibly with some APIs directly in the root module)?
Most Clang submodules allow importing a subset of APIs, but still import everything by default with the top-level module. Explicit submodules are the exception rather than the common case. > >> - C++ namespacing within a module > > This is perhaps the most straightforward goal, but I believe it would be > better served by a more robust submodule feature rather than being a limited > namespace feature (for example, integrating with the subset import mentioned > above). > >> - C++ namespacing within another module > > Can you elaborate? Do you mean namespaces that are “open to extension” in > any module similar to how we can extend types from imported modules, provide > retroactive conformances, etc? If that is what you mean I am not at all > convinced there is value in this. import Foo Foo.Bar.baz() It’s not obvious that a namespace within the main module (the module currently being compiled) shouldn’t be flattened when the module is published—say, if things are only broken up for compilation time purposes. Alternately, it’s not obvious that the namespaces within a module match up to the units you want to be able to import as submodules. > >> - breaking up compilation units (i.e. not compiling the entire module as one >> unit) > > This feels like it could be a build setting independent of submodules. For > example, if you want WMO to span all submodules you wouldn’t necessarily want > this, but if WMO isn’t important maybe you do. People mostly want this for compile time. > >> - adding another access level between internal and fileprivate. > > This obviously makes sense in the context of a submodule (or namespace) > feature, but feels (to me) like it would be awkward as an independent > feature. > >> - adding another access level between fileprivate and private. > > Are you thinking of a file that contains scopes from different submodules? > I’m trying to think of how this would do something that the new `private` > wouldn’t already be able to do. A few people would prefer to break a file up into (disjoint) groups rather than have groupings across files. I personally think this would not be a good feature, but it goes on the list. > >> - something else? > > The big ones IMO are API subsets, namespaces, and encapsulation (access > control) which feel like they fit very nicely together as a single elegant > submodule feature. “80% of the users only need 20% of the features, but everybody uses a different 20%”. I’d be happy to have one feature that serves multiple purposes; however, in any such proposal I don’t want to take any behavior as obvious, because in the last three years someone has at one point asked for the opposite. :-) Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
