| -----Original Message-----
| From: tooling-bounces_at_open-std.org <tooling-bounces_at_open-std.org> On
| Behalf Of Matthew Woehlke
| Sent: Monday, February 4, 2019 9:43 AM
| To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]rg>
| Subject: Re: [Tooling] Modules
|
| (Apologies for misthreading; I, too, seem to be missing a non-trivial
| chunk of messages being sent to this list :'(.)
|
| On Friday, February 1, 2019 1:10 PM, Gabriel Dos Reis wrote:
| > With modules, I expect the number of files need needing scanning for
| > dependency to be small. Of course if you adopt a programming style
| > that conflates modules with Java classes, where you get one module
| > per class, you get what you ask for…
|
| Wasn't that the point of modules?

No, one module per class wasn't a design goal.

| My impression was that modules are
| intended to deprecate #include, which would result in very few files
| that do *not* depend on at least one module.
|
| ...or am I missing something in the above?

Quoting from the design document (section 4.1) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf

 # While many of the problems with the existing copy-and-paste methodology can be directly tied to
# the nature of the preprocessor, this proposal suggests neither its eradication nor improvements of it.
# Rather, the module system is designed to co-exist with and to minimize reliance on the preprocessor.
# We believe that the pre-processor has been around for far too long and supports far too many creative
# usage for its eradication to be realistic in the short term.
# [...]
# A central tenet of this proposal is that a module system for C++ has to be an evolution of
# the conventional compilation model. The immediate consequence is that it has to inter-operate with
# the existing source file inclusion model while solving the significant problems and minimizing
# those that can’t be completely solved.

-- Gaby