On 7/11/19 4:26 PM, Gabriel Dos Reis via Modules wrote:
>
> If you systematically translate ‘#include <foo>’ to ‘import <foo>;’
> then code written for C++17 has just been broken both from semantics
> perspective and from build perspective. I can’t fathom a world where
> that is a positive thing.
>
> To be incrementally adoptable, the include translation has to be
> opt-in in a way that is more than “yeah but you are compiling in C++20
> mode, so you asked for it.”
>
I agree, that is what is accomplished by the module map.

Tom.

> *From:*Tom Honermann <tom_at_[hidden]>
> *Sent:* Thursday, July 11, 2019 1:13 PM
> *To:* modules_at_[hidden]; sg15_at_[hidden]
> *Cc:* Gabriel Dos Reis <gdr_at_[hidden]>; Bryce Adelstein Lelbach
> aka wash <brycelelbach_at_[hidden]>
> *Subject:* Re: [isocpp-modules] [SG15] Determining identity like
> #pragma once
>
> 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.
>
>
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/07/0537.php