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@honermann.net>
Sent: Thursday, July 11, 2019 1:13 PM
To: modules@lists.isocpp.org; sg15@lists.isocpp.org
Cc: Gabriel Dos Reis <gdr@microsoft.com>; Bryce Adelstein Lelbach aka wash <brycelelbach@gmail.com>
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@lists.isocpp.org
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
Link to this post: http://lists.isocpp.org/modules/2019/07/0537.php