On Fri, Sep 20, 2019 at 3:02 PM Boris Kolpackov <boris_at_[hidden]>
wrote:

> Mathias Stearn <redbeard0531+isocpp_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.