[Tooling] Modules naming

Tom Honermann tom at honermann.net
Fri Jan 11 04:55:35 CET 2019


On 1/10/19 6:14 PM, Ville Voutilainen wrote:
> On Fri, 11 Jan 2019 at 01:02, Corentin <corentin.jabot at gmail.com> 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.

I think of the problem a little differently.  For myself, I would like 
to see more demonstration that modules as proposed can be used at scale 
(e.g., 100+ modules) before voting to approve the feature for inclusion 
into the standard.  My concern isn't with the specification, it is with 
the ability to adopt the feature at all.  We have plenty of evidence of 
Clang modules being adoptable at scale, but Clang modules doesn't have 
the module name/file map concern.  If someone can show that the map 
concern is not a large impediment to adoption (nor a drag on IDEs and 
other tools), then I'll be much happier to vote to adopt modules as 
proposed into the WP.  Until then, I remain quite worried about 
adoptability and impact on existing tools/IDEs.

Tom.



More information about the Tooling mailing list