> On Jun 22, 2016, at 11:59 AM, Jordan Rose via swift-evolution > <[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: > > - 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. -DW
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
