On 7/11/19 8:36 AM, Gabriel Dos Reis via Modules wrote:
>
> * It seem like a net-negative change to make #include <foo> and
> import <foo> mean different things in cases where both are
> well-formed.
>
> I think that is an inevitable practical necessity.
>
> Actually, I think it is a real net-positive: we can practically deploy
> it, enable incremental adoption, and update the toolchains to identify
> incoherent context settings.
>
I strongly disagree with this being a net-positive. If programmers
can't rely on translation of #include <foo> to import <foo>, then code
written to compile for C++17 and C++20 can't take advantage of modules
when compiled as C++20 unless the code is #ifdef'd to use #include in
C++17 mode and import in C++20 mode. This hurts the incremental
adoption story.

Clang modules took the approach that importable headers must be defined
in a module map. My expectation has been that the SG15 TR would
(eventually) specify a portable map format to enable specifying which
headers are importable. That remains my preference. As a programmer, I
want to be able to control which of my headers are importable; it
matters from a build system perspective because I may want to pre-build
module artifacts for a select set of headers (ideally a set that the
build system learns from the module map file(s); assuming compilers
provide the ability to explicitly generate module artifacts for header
units).

Tom.