Date: Thu, 10 Jan 2019 22:55:35 -0500
On 1/10/19 6:14 PM, Ville Voutilainen wrote:
> 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.
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.
> 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.
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.
Received on 2019-01-11 05:01:43