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. I suggest
one of the two alternatives:
1) To have a special type of import, `#import`.
2) have a kind of “PCH” file where we can list all modules we want to be
globally available at project scope.
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.
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. I
suggest one of the two alternatives:
1) To have a special type of import, `#import`.
2) have a kind of “PCH” file where we can list all modules we want to be
globally available at project scope.
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`).
-Van
···
On Mon, Feb 8, 2016 at 8:30 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
> import (project scope import)
> [swift-evolution] #import (project scope import) (former: "Pre-imported modules (sort of PCH)”)
>
> Pre-imported modules (sort of PCH)
> [swift-evolution] 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.