<div dir="ltr">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.<div>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).<div><div><div><div><div><br></div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 10 Jan 2019 at 18:47 JF Bastien <<a href="mailto:cxx@jfbastien.com">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 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>
</blockquote></div>