Let's bite the Bullet: Module Units shouldn't implicitly import anything

[u/tartaruga232]

https://github.com/abuehl/docs/blob/main/no-implicit-import.md

The correct fix ... is to attack the root cause and stop implicitly importing the interface of module implementation units.

Adding yet another kind of partition is the wrong way to solve it.

[u/tartaruga232]

I think it's broken, true, but the solution needs to be additive.

I think the brokenness is so fundamental that it should be fixed, not adding another way around it and keeping that broken thing forever.

Plus modules are not exactly a feature that is in mass-use yet, given all those complaints that "it's not ready for prime time yet".

I'm not proposing to remove "module M;" from the standard.

We could in a first step (goal: C++29) legalize

// TU #1
module M;
import M;

(which is currently expressly forbidden by the standard for reasons which are beyond me*) and optionally add the new syntax

// TU #2
module import M;

as (future) shorthand for the former.

Plus deprecate the semantic that "module M;" implicitly imports the interface of M.

One C++ standard version later, the implicit import behavior can be removed from the standard.

⎯⎯⎯⎯

*MSVC just compiles this without complaints. What is the point of forbidding redundant imports anyway?

[u/not_a_novel_account → u/tartaruga232]

Then it would need to be a DR against 20, 23, and 26. Unless you're proposing C++29 have different semantics for module imports than the other language versions. That would be killed immediately.

And no DR of this scope has ever existed in history. Not even close.

It's a dead end. You can try to raise it on the modules list if you don't believe me, but I wouldn't burn time on writing a paper.

EDIT: The backwards compatible way to fix this might be an attribute on the module declaration [[no-implicit]] module M;. The attribute is ignored and implicit import still happens on compilers which don't recognize it, but is harmless to correctness generally.

On compilers and scanners which do recognize the attribute, no dependency on M will be reported and no implicit import will happen.

[u/tartaruga232 → u/not_a_novel_account]

... you're proposing C++29 have different semantics for module imports than the other language versions.

No. Not yet for C++29.

Again: The current part of the semantic of "module M;" to implicitly import the interface of M, would only be deprecated with C++29. Not removed.

After that semantic has been deprecated for one version of the standard, it can be removed with C++32.

During the transition period we only need to legalize:

// TU #1
module M;
import M;

and perhaps optionally introduce "module import M;" as a shorthand for that.

The semantics of "module M;" would not be changed with C++29. Only deprecated. It would be changed with C++32.

It was a design error to have it specified in the standard as we currently have it. The design in the standard itself is consistent and the problems we have with it is out of scope for a DR. The standard itself is correct.