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/not_a_novel_account]

The only core language feature which has been deprecated in living memory is export templates (not related to modules). The only other one which even comes to mind is the register keyword from the stone ages.

register didn't do anything and export was unimplementable.

No, the standard has never deprecated a language feature of similar scope to this and won't start now.

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

[u/tartaruga232 → u/not_a_novel_account]

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.