On Fri, 11 Jan 2019 at 01:02, Corentin <corentin.jabot_at_[hidden]> wrote:
>
> As I said, I want to talk about the problem rather than a specific solution.
>
> Now, we can all assume that modules as specified will be supported without pain by all build systems, IDEs, refactoring tools etc in a way that is efficient, scalable, distributable, easy to use and compatible with SG15 dependencies manager ambitions.
>
> But, I have enough reservation that I would not be comfortable voting for a merge of the proposal any time soon.
> If people proposing changes to the proposal have a burden of proof, maybe so should the people that keep on insisting that everything is perfect as it is?
>
> Modules are by nature quite invasive. Not only will they require module-aware build system to be usable, but so will any downstream users. Sticking "-std=c++20" on gcc won't let people magically use modules everywhere.
> There is a risk that the feature will be ignored or make libraries that elect to use modules unusable. And modules have enough benefits to offer that we should do everything we can to avoid that.
>
>
> So maybe you are right that we need more implementation.

Here's a question, though: what in the current specification
*prevents* mappings and discovery that work well with tooling? The
proposals/suggestions you have
seem like they are aimed to be restrictions that would prevent
mappings and discovery that are hard for tools, which is a laudable
goal. However,
the current specification says absolutely nothing about module name
mappings and such, which is not an accident - it's by design, and the
way
a language specification is supposed to be written, without
overspecifying how tools operate.

*That* is the proof that JF seeks; a proof that you absolutely have to
change the current specification to be able to build modules sanely.
If you already
can, as long as certain conventions are followed, then there is no
absolute need to change the specification.