<div dir="ltr">> <span style="color:rgb(33,33,33)">When I say "implementation experience for modules" I mean: I have </span><span style="color:rgb(33,33,33)">code, I compile it with a compiler. That's pretty much the whole story.</span><div><br></div><div dir="ltr"><div><span style="color:rgb(33,33,33)">That's exactly my point, this is not the whole story: You most likely have a build system invoking the compiler for you.</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">We know that modules work great at the compiler level and I don't think anyone has issues with modules as a language feature.</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">However, import statements impact the order in which individual translations units need to be built by the build system ( cmake, msbuild, b2, pick your poison).</span></div><div><span style="color:rgb(33,33,33)">We know that this works if dependencies are specified manually, but we know that it is not manageable to do so above a handful of modules.</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">Instead, the build system manage the dependency graph which brings a lot of interesting challenges that are not the responsibility of compilers (as we understand them in C++) so there are a lot more pieces</span></div><div><span style="color:rgb(33,33,33)">in the equation (and modules do not behave at all like headers from a build system standpoint).</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">So we cannot Godbolt away the concerns we may have about modules, unfortunately. </span></div><div><br></div><div><span style="color:rgb(33,33,33)">Now, I have thought a lot about the issue, I think this is (one of the problem) needing solving, and I humbly suggest a few things that I think would alleviate some of the issues. </span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">I might be wrong about the problem or misguided about the solution.</span></div><div><span style="color:rgb(33,33,33)"> However, writing the tools and having large enough codebases to play with is a significant investment which could occupy several people </span><span style="color:rgb(33,33,33)">for a few months if they had nothing else to do.</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div>Working on theory, I think it is still preferable to be too restrictive ( and then lift the restriction ) than not enough and not be able to do anything about it (restricting the way modules are named or mapped after C++20 ships would be a massive breaking change.</div><div><br></div><div>So am I sure something needs to be done regarding the way modules are mapped to files? No, even if I strongly suspect so.</div><div>But, are you sure it is in fact not necessary?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 10 Jan 2019 at 22:26 JF Bastien <<a href="mailto:cxx@jfbastien.com" target="_blank">cxx@jfbastien.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jan 10, 2019 at 1:18 PM Corentin <<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>> wrote:<br>
><br>
> It is a chicken and egg problem.<br>
<br>
I don't think you're answering the question I asked, but you are<br>
pointing out a problem: SG15 doesn't have a large modularized<br>
codebase. Why not focus efforts on creating one, so that SG15's<br>
efforts can be grounded in facts?<br>
<br>
<br>
> Integrating modules in build systems will be a tedious endeavor - especially in meta build systems,<br>
> and there is little incentive to do that before modules get merged.<br>
><br>
> It would be rather inconvenient to realize modules are not reasonably consumed by build system _after_ the IS is published.<br>
><br>
> While having large modularized projects and build systems would be nice, it's a luxury we don't seem to have.<br>
<br>
You can create one. Or you can take the luxury of talk and suggest<br>
restrictions to modules, without grounding that talk in facts. I'm<br>
saying that you want more than just talk.<br>
<br>
<br>
> And I think taking a long look at module toolability (both in term of current tools. and in term of the 10 years goals/hopes this group has for tooling) falls in SG15 purview.<br>
<br>
Totally agree, but you can't tool with talk. At least when it comes to<br>
C++, you need code.<br>
<br>
<br>
> While my own experience is limited, I trust this group has enough build system experience and knowledge to foresee eventual issues and correct for them.<br>
> We can also extrapolate from the well-known issue of headers name collision that exists and the guidelines that arose from that.<br>
><br>
> It is important to be explicit about what we mean when we say "implementation experience" when talking about modules because they exist at the border between language and tools<br>
> and having compiler implementation experience isn't the whole story.<br>
<br>
When I say "implementation experience for modules" I mean: I have<br>
code, I compile it with a compiler. That's pretty much the whole<br>
story.<br>
<br>
<br>
> On Thu, 10 Jan 2019 at 21:39 JF Bastien <<a href="mailto:cxx@jfbastien.com" target="_blank">cxx@jfbastien.com</a>> wrote:<br>
>><br>
>> On Thu, Jan 10, 2019 at 11:52 AM Corentin <<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>> wrote:<br>
>> ><br>
>> > I suspect it will be a while (several years) before we start to see large projects transitioning fully to modules and consumed as such by tools doing automatic dependency scanning etc.<br>
>> > My understanding is that there is little large scale implementation experience as far as tooling and build systems are concerned ( there is plenty _compilers_ implementation experience, and some build system implementation (and usage of modules) experience - mostly in build2).<br>
>><br>
>> Given your statement above, why is it useful for SG15 to discuss<br>
>> enforcing mapping? Specifically, how will that discussion be grounded<br>
>> in facts? It seems to me like facts need a compiler implementation,<br>
>> and a codebase to try it out on. Feel free to talk about hypotheticals<br>
>> all you want, but in this case code wins.<br>
>><br>
>> I think you want to refocus your approach: what are you trying to<br>
>> achieve? What's the advantage that SG15 has, which the modules SG and<br>
>> now EWG don't have? How can SG15 contribute module's success?<br>
>><br>
>><br>
>> > On Thu, 10 Jan 2019 at 18:47 JF Bastien <<a href="mailto:cxx@jfbastien.com" target="_blank">cxx@jfbastien.com</a>> wrote:<br>
>> >><br>
>> >> On Thu, Jan 10, 2019 at 6:53 AM Corentin <<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> > Hello.<br>
>> >> > I would like to suggest two modules related proposals that I think SG15 should look at.<br>
>> >> ><br>
>> >> > - Compiler enforced mapping between module names and module interface file (resource) name.<br>
>> >><br>
>> >> Why does SG15 need to do this, versus someone implementing it in an<br>
>> >> open-source toolchain, trying it out, and bringing what using it<br>
>> >> taught them to SG15?<br>
>> >><br>
>> >><br>
>> >> > Currently, modules interfaces can be declared in any file - which makes dependency scanning more tedious than it needs to be and have performance implications<br>
>> >> > (The build system needs to open all files to gather a list of modules) - notably when the build system tries to start building while the dependency graph isn't yet complete.<br>
>> >> ><br>
>> >> > Tools ( ide, code servers, indexers, refactoring) may also greatly benefit from an easier way to locate the source file which declares a module.<br>
>> >> ><br>
>> >> > The specifics of the mapping are open to bikeshedding. However, I think we would have better luck sticking to something simple like <module identifier> <=> <file name>.<extension><br>
>> >> > (The standardese would mention resource identifier rather than filename)<br>
>> >> ><br>
>> >> > - A standing document giving guidelines for modules naming.<br>
>> >> ><br>
>> >> > The goal is to take everything the community had to learn the hard way about header naming over the past 30 years and apply it to modules by providing a set of guidelines<br>
>> >> > that could be partially enforced by build system vendors.<br>
>> >> > Encouraging consistency and uniqueness of module identifiers across the industry is I think a necessary step towards sane package management.<br>
>> >> > Note that the standard requires uniqueness of modules identifiers within (the standard definition of) a program but says little about a way to ensure this uniqueness.<br>
>> >> ><br>
>> >> > Here is a rough draft of what I think would be good guidelines, partially inspired by what is done by other languages facing similar issues.<br>
>> >> ><br>
>> >> > Prefix module names with an entity and/or a project name to prevent modules from different companies, entities and projects of declaring the same module names.<br>
>> >> > Exported top-level namespaces should have a name identic to the project name used as part of the name of the module(s) from which it is exported.<br>
>> >> > Do not export multiple top-level namespaces<br>
>> >> > Do not export entities in the global namespace outside of the global module fragment.<br>
>> >> > Organize modules hierarchically. For example, if both modules example.foo and example.foo.bar exist as part of the public API of example, example.foo should reexport example.foo.bar<br>
>> >> > Avoid common names such as util and core for module name prefix and top-level namespace names.<br>
>> >> > Use lower-case module names<br>
>> >> > Do not use characters outside of the basic source character set in module name identifiers.<br>
>> >> ><br>
>> >> > My hope is that these 2 proposals (whose impact on the standard is minimal) would make it easier for current tooling to deal with modules<br>
>> >> > while making possible for example to design dependency managers and build systems able to work at the module level.<br>
>> >> ><br>
>> >> > I'd love to gather feedback and opinions before going further in that direction.<br>
>> >> > Thanks a lot!<br>
>> >> ><br>
>> >> > Corentin<br>
>> >> ><br>
>> >> > PS: For a bit of background, I talked about these issues there<br>
>> >> ><br>
>> >> > <a href="https://cor3ntin.github.io/posts/modules_mapping/" rel="noreferrer" target="_blank">https://cor3ntin.github.io/posts/modules_mapping/</a><br>
>> >> > <a href="https://cor3ntin.github.io/posts/modules_naming/" rel="noreferrer" target="_blank">https://cor3ntin.github.io/posts/modules_naming/</a><br>
>> >> ><br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > Tooling mailing list<br>
>> >> > <a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
>> >> > <a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
>> >> _______________________________________________<br>
>> >> Tooling mailing list<br>
>> >> <a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
>> >> <a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > Tooling mailing list<br>
>> > <a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
>> > <a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
>> _______________________________________________<br>
>> Tooling mailing list<br>
>> <a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
>> <a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
><br>
> _______________________________________________<br>
> Tooling mailing list<br>
> <a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
> <a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div>