[swift-evolution] Submodules (was: A Problem With SE-0025?)

[Jordan Rose]

> On Jun 22, 2016, at 12:04, David Waite <david at alkaline-solutions.com> wrote:
> 
> 
>> On Jun 22, 2016, at 11:59 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/c13b5eb2/attachment.html>