[swift-evolution] Module importation at project scope
vmartinelli at alecrim.com
Tue Feb 16 13:52:39 CST 2016
Yes, I understand the purpose of the PCH file and I agree with you, but its
side effects were mentioned in the context of my suggestion explanation.
About pre-importing modules: currently Swift already has support for
something like this when using bridging headers for Objective-C
interoperability. I'm suggesting the same behaviour for Swift-only files
using a special file or a special type of import (maybe `#import`).
On Mon, Feb 8, 2016 at 8:30 PM, Brent Royal-Gordon <brent at architechies.com>
> > #import (project scope import)
> > Pre-imported modules (sort of PCH)
> > In many languages, including Swift, when we are developing apps
> (frameworks are other history), we have to include/import dozens of
> libraries references. The proposal is to have for app projects (maybe not
> for frameworks projects) a way to say to Swift compiler that we are using
> some module everywhere in the project code files, so we can expect the
> module to be always available without a `import` on the top of each file.
> Swift seems to generally have a philosophy where the interpretation of a
> file shouldn't depend on global context, like compiler error switches. It
> seems to me that these features would violate that rule.
> In particular, it's worth keeping in mind that the actual purpose of a PCH
> is not to reduce the number of imports in the text of each C file, but to
> precompile large, widely-included headers once so they don't need to be
> compiled separately for every file. That's the "PC" in "PCH". Using a PCH
> to reduce boilerplate is actually abusing the mechanism.
> Brent Royal-Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution