> On Jun 22, 2016, at 12:04, David Waite <da...@alkaline-solutions.com> wrote: > > >> On Jun 22, 2016, at 11:59 AM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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: >> >> - importing a subset of APIs >> - having APIs not imported by default with the top-level module >> - C++ namespacing within a module >> - C++ namespacing within another module >> - breaking up compilation units (i.e. not compiling the entire module as one >> unit) >> - adding another access level between internal and fileprivate. >> - adding another access level between fileprivate and private. >> - something else? > > Aggregation of first and third party frameworks into a single linkable module > might be on that pile, if such aggregation was a path decided on to reduce > application startup time.
I'd consider that an implementation detail of linking and a feature request for Xcode and the package manager rather than a language feature, but yes, I would also not call that "submodules". :-) Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
