Concrete examples will help in understanding what is actual realistic scenarios.

-- Gaby
________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of Mathias Stearn via SG15 <sg15_at_[hidden]>
Sent: Friday, September 20, 2019 1:19:54 PM
To: Boris Kolpackov <boris_at_[hidden]>
Cc: Mathias Stearn <redbeard0531+isocpp_at_[hidden]>; sg15_at_[hidden] <sg15_at_[hidden]>
Subject: Re: [SG15] Paper for Saturday CppCon Tooling meeting: remove.dots.in.module.names



On Fri, Sep 20, 2019 at 3:02 PM Boris Kolpackov <boris_at_[hidden]<mailto:boris_at_[hidden]>> wrote:
Mathias Stearn <redbeard0531+isocpp_at_[hidden]<mailto:redbeard0531%2Bisocpp_at_[hidden]>> writes:

> But the current semantics of the syntax a.b differs from a:b in more ways
> than just whether the submodule is publicly importable or not. With a.b,
> the a module and other submodules of a are unable to forward declare types
> owned by a.b, and vice-versa. With a:b, forward declaration is legal for
> all entities owned by the a module. Additionally, a:b-submodules have
> access to each others module-linkage entities, while a.b-submodules do not.

And that's a good thing: if your entities are related, put them into
the same module (and use partitions if you need to organize things
inside).

But that affects the public API since it dictates the granularity of publically importable modules. And it allows implementation concerns, such as what forward declarations and internal helpers are used in the definitions to dictate that API. This means that libraries should probably never expose granular modules because it limits how much they can alter their implementation details. Alternatively, they can implement everything in a detail module and namespace, and use export using declarations to put entities in their desired public namespace and modules. Or just forgo the whole ownership thing with extern "C++" all-the-things.

That seems like a less than ideal situation to me.