<div dir="ltr">Hello.<div>I would like to suggest two modules related proposals that I think SG15 should look at.<br></div><div><br></div><div>-<b> Compiler enforced mapping between module names and module interface file (resource) name. </b></div><div><br></div><div>Currently, modules interfaces can be declared in any file - which makes dependency scanning more tedious than it needs to be and have performance implications</div><div>(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&#39;t yet complete.</div><div><br></div><div>Tools ( ide, code servers, indexers, refactoring) may also greatly benefit from an easier way to locate the source file which declares a module.</div><div><br></div><div>The specifics of the mapping are open to bikeshedding. However, I think we would have better luck sticking to something simple like &lt;module identifier&gt; &lt;=&gt; &lt;file name&gt;.&lt;extension&gt;</div><div>(The standardese would mention <i>resource identifier</i> rather than filename)</div><div><br></div><div>- <b>A standing document giving guidelines for modules naming.</b></div><div><br></div><div>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</div><div>that could be partially enforced by build system vendors.</div><div>Encouraging consistency and uniqueness of module identifiers across the industry is I think a necessary step towards sane package management.</div><div>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.</div><div><br></div><div>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.</div><div><div><ul style="box-sizing:inherit;margin:1em 2em 1.5em;padding:0px;border:0px;vertical-align:baseline;background-image:initial;background-position:0px 0px;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;list-style-position:initial;color:rgb(66,70,76);font-family:&quot;Open Sans&quot;,sans-serif"><li style="box-sizing:inherit;margin:0px;padding:0px;border:0px;vertical-align:baseline;background:0px 0px"><span style="box-sizing:inherit;color:rgb(34,35,36);margin:0px;padding:0px;border:0px;font-weight:700;vertical-align:baseline;background:0px 0px"><font size="1">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.</font></span></li><li style="box-sizing:inherit;margin:0.25em 0px 0px;padding:0px;border:0px;vertical-align:baseline;background:0px 0px"><span style="box-sizing:inherit;color:rgb(34,35,36);margin:0px;padding:0px;border:0px;font-weight:700;vertical-align:baseline;background:0px 0px"><font size="1">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.</font></span></li><li style="box-sizing:inherit;margin:0.25em 0px 0px;padding:0px;border:0px;vertical-align:baseline;background:0px 0px"><span style="box-sizing:inherit;color:rgb(34,35,36);margin:0px;padding:0px;border:0px;font-weight:700;vertical-align:baseline;background:0px 0px"><font size="1">Do not export multiple top-level namespaces</font></span></li><li style="box-sizing:inherit;margin:0.25em 0px 0px;padding:0px;border:0px;vertical-align:baseline;background:0px 0px"><span style="box-sizing:inherit;color:rgb(34,35,36);margin:0px;padding:0px;border:0px;font-weight:700;vertical-align:baseline;background:0px 0px"><font size="1">Do not export entities in the global namespace outside of the global module fragment.</font></span></li><li style="box-sizing:inherit;margin:0.25em 0px 0px;padding:0px;border:0px;vertical-align:baseline;background:0px 0px"><font size="1"><span style="box-sizing:inherit;color:rgb(34,35,36);margin:0px;padding:0px;border:0px;font-weight:700;vertical-align:baseline;background:0px 0px">Organize modules hierarchically.</span> For example, if both modules <code style="box-sizing:inherit;margin:0px;padding:1px 2px 2px;border:0px;vertical-align:baseline;background:0px 0px transparent;font-family:&quot;Source Code Pro&quot;,Monaco,Inconsolata,monospace;line-height:1.25;color:inherit">example.foo</code> and <code style="box-sizing:inherit;margin:0px;padding:1px 2px 2px;border:0px;vertical-align:baseline;background:0px 0px transparent;font-family:&quot;Source Code Pro&quot;,Monaco,Inconsolata,monospace;line-height:1.25;color:inherit">example.foo.bar</code> exist as part of the public API of <code style="box-sizing:inherit;margin:0px;padding:1px 2px 2px;border:0px;vertical-align:baseline;background:0px 0px transparent;font-family:&quot;Source Code Pro&quot;,Monaco,Inconsolata,monospace;line-height:1.25;color:inherit">example</code>, <code style="box-sizing:inherit;margin:0px;padding:1px 2px 2px;border:0px;vertical-align:baseline;background:0px 0px transparent;font-family:&quot;Source Code Pro&quot;,Monaco,Inconsolata,monospace;line-height:1.25;color:inherit">example.foo</code> should reexport <code style="box-sizing:inherit;margin:0px;padding:1px 2px 2px;border:0px;vertical-align:baseline;background:0px 0px transparent;font-family:&quot;Source Code Pro&quot;,Monaco,Inconsolata,monospace;line-height:1.25;color:inherit">example.foo.bar</code></font></li><li style="box-sizing:inherit;margin:0.25em 0px 0px;padding:0px;border:0px;vertical-align:baseline;background:0px 0px"><span style="box-sizing:inherit;color:rgb(34,35,36);margin:0px;padding:0px;border:0px;font-weight:700;vertical-align:baseline;background:0px 0px"><font size="1">Avoid common names such as <code style="box-sizing:inherit;margin:0px;padding:1px 2px 2px;border:0px;font-weight:400;vertical-align:baseline;background:0px 0px transparent;font-family:&quot;Source Code Pro&quot;,Monaco,Inconsolata,monospace;line-height:1.25;color:inherit">util</code> and <code style="box-sizing:inherit;margin:0px;padding:1px 2px 2px;border:0px;font-weight:400;vertical-align:baseline;background:0px 0px transparent;font-family:&quot;Source Code Pro&quot;,Monaco,Inconsolata,monospace;line-height:1.25;color:inherit">core</code> for module name prefix and top-level namespace names.</font></span></li><li style="box-sizing:inherit;margin:0.25em 0px 0px;padding:0px;border:0px;vertical-align:baseline;background:0px 0px"><span style="box-sizing:inherit;color:rgb(34,35,36);margin:0px;padding:0px;border:0px;font-weight:700;vertical-align:baseline;background:0px 0px"><font size="1">Use lower-case module names</font></span></li><li style="box-sizing:inherit;margin:0.25em 0px 0px;padding:0px;border:0px;vertical-align:baseline;background:0px 0px"><span style="box-sizing:inherit;color:rgb(34,35,36);margin:0px;padding:0px;border:0px;font-weight:700;vertical-align:baseline;background:0px 0px"><font size="1">Do not use characters outside of the basic source character set in module name identifiers.</font></span></li></ul></div></div><div>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></div><div>while making possible for example to design dependency managers and build systems able to work at the module level.</div><div><br></div><div>I&#39;d love to gather feedback and opinions before going further in that direction.</div><div>Thanks a lot!</div><div><br></div><div>Corentin</div><div><br></div><div>PS: For a bit of background, I talked about these issues there</div><div><br></div><div><a href="https://cor3ntin.github.io/posts/modules_mapping/">https://cor3ntin.github.io/posts/modules_mapping/</a></div><div><a href="https://cor3ntin.github.io/posts/modules_naming/">https://cor3ntin.github.io/posts/modules_naming/</a><br></div><div><br></div><div> </div></div>