Date: Thu, 11 Jul 2019 20:26:22 +0000
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.”
From: Tom Honermann <tom_at_[hidden]>
Sent: Thursday, July 11, 2019 1:13 PM
To: modules_at_lists.isocpp.org; 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.
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.”
From: Tom Honermann <tom_at_[hidden]>
Sent: Thursday, July 11, 2019 1:13 PM
To: modules_at_lists.isocpp.org; 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.
Received on 2019-07-11 15:28:17