<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, 12 Jan 2019 at 06:23 Tom Honermann &lt;<a href="mailto:tom@honermann.net">tom@honermann.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <div class="m_7953253774571895280moz-cite-prefix">On 1/11/19 6:04 PM, Corentin wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr"><br>
        <br>
        <div class="gmail_quote">
          <div dir="ltr">On Fri, 11 Jan 2019 at 23:31 Tom Honermann &lt;<a href="mailto:tom@honermann.net" target="_blank">tom@honermann.net</a>&gt;
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <div class="m_7953253774571895280m_-7578053289813035424moz-cite-prefix">On
                1/11/19 9:29 AM, Ben Craig wrote:<br>
              </div>
              <blockquote type="cite">
                <div class="m_7953253774571895280m_-7578053289813035424WordSection1">
                  <p class="MsoNormal">&gt; The manifest file could be
                    generated (based on information in source code) and</p>
                  <p class="MsoNormal">&gt; usable by multiple tools,
                    IDEs, and build systems.  It need not be a
                    statically</p>
                  <p class="MsoNormal">&gt; maintained file.  I like
                    this approach because it appropriately separates the</p>
                  <p class="MsoNormal">&gt; steps of
                    identifying/building the module name/file map vs
                    using the module</p>
                  <p class="MsoNormal">&gt; name/file map (most tools
                    don&#39;t want to be build systems).</p>
                  <p class="MsoNormal"> </p>
                  <p class="MsoNormal">This sounds like a clang
                    compilation database.</p>
                </div>
              </blockquote>
            </div>
          </blockquote>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">I don&#39;t think so.  It
              is a database, but not one that stores the history of how
              a build was performed.  Rather, it stores some of the
              information that would be needed to construct a compiler
              invocation (or for a tool/IDE to parse source files that
              require resolving module names to source files).</div>
          </blockquote>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>It&#39;s exactly what a compilation database is ( it includes
            informations such as include directories, defines and some
            flags) for every translation unit</div>
        </div>
      </div>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    I think of the manifest file as more of a meta-build thing.  I think
    of a compilation database as something that records the operations
    that were done as part of a build, not the instructions for how to
    do a build.  Perhaps my perspective on this is unique.</div></blockquote><div><br></div><div>I think it is - tools now provide ways to generate that file without doing the actual build and it only specifies how to build translations units, not whole programs.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <blockquote type="cite">
                <div class="m_7953253774571895280m_-7578053289813035424WordSection1">
                  <p class="MsoNormal">Such a thing is useful for
                    non-build tools, and can be generated automatically,
                    as you said.  I am concerned that generating such a
                    file early in the build process would cause
                    performance problems.  Each source file would need
                    to be partially parsed before the build DAG could be
                    fully formed.  However, I don’t have benchmarks
                    indicating how expensive an extra pass over all the
                    source files is.</p>
                </div>
              </blockquote>
            </div>
            <div bgcolor="#FFFFFF" text="#000000">
              <p>Without such a file (or equivalent information
                statically encoded in &quot;the&quot; build system), the only
                alternative is to examine every source file in order to
                construct the build DAG in memory anyway.  How else
                could such a scan be avoided?  </p>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Build systems will always need to parse every file at
            least once before invoking the build.<br>
          </div>
          <div>They can hopefully extract both the name and the
            dependency in a single pass.</div>
        </div>
      </div>
    </blockquote>
    </div><div bgcolor="#FFFFFF" text="#000000"><p>Unless the information is already available elsewhere.<br>
    </p>
    <p>I feel like this point keeps getting missed.  We use many tools
      that require semantic analysis.  Many of those tools today do not
      have anything that we would call a build system.  They might be
      configured with a collection of include paths and macro
      definitions, but that is pretty much it.  I think too much of this
      discussion is in regard to &quot;the&quot; build system and not enough on
      how IDEs/tools will function (preferably collaboratively) in a
      modular world.  How are vim and emacs going to resolve module
      imports?<br></p></div></blockquote><div><br></div><div>I think you are right - Build systems and code analysis tools, including IDE will need to cope differently.</div><div>The discussion of how symbols will be extracted from a file importing modules is very important indeed, especially for your usecase.</div><div><br></div><div>Note that if modules are not tied to the filename, they can easily be renamed at any time by the developer which implies that modifying a file</div><div>requires the mapping file you want to be regenerated.</div><div>The dependency graph of modules is much more dynamic.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><p>
    </p></div><div bgcolor="#FFFFFF" text="#000000">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>The issue with lack of module mapping is that the build
            system can&#39;t really have a top-down</div>
          <div>approach that would ensure some nodes of the build graph
            are fully resolved soon after</div>
          <div>the build starts.</div>
        </div>
      </div>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    I don&#39;t see this issue as an artifact of a module mapping
    requirement but rather the separate compilation model for modules. 
    It is exactly equivalent to complications with generated headers
    today.  Knowing the module interface unit file name doesn&#39;t tell you
    which source files have a dependency on it.</div></blockquote><div><br></div><div>I was thinking the other way around.</div><div>When you know that foo.cpp depends on module bar, if you have a O(1) mechanism to map bar to a file, you can prioritize the scanning of the corresponding file until all transitives dependencies of foo.cpp are complete and you can start to build the DAG towards that node without waiting the analysis of the whole project to be complete.</div><div>If the module mapping is in O(n), the best strategy for the build system is to open files &quot;randomly&quot; and filling the blanck as it goes.</div><div><br></div><div>Does that makes sense ?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <p>(There is another alternative; implicitly building
                modules on demand as is done for Clang modules today. 
                But to my knowledge, no implementors are pursuing that
                for standard proposed modules).</p>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>I imagine this would solve a lot of issues : Give the
            compiler a bunch of source files and let it figure things
            out. It&#39;s more or less how rust and go works unless I&#39;m
            mistaking?</div>
        </div>
      </div>
    </blockquote>
    </div><div bgcolor="#FFFFFF" text="#000000"><p>It solves some, but it has some scaling issues as well,
      particularly when a module must be built (and cached) multiple
      times to satisfy different sets of compilation options by
      different consumers.  Also due to the need for parallel compiler
      invocations to synchronize.</p></div></blockquote><div><br></div><div>I had not thought of that second point... that&#39;s... an interesting problem. gosh !</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <p>Tom.<br>
    </p></div><div bgcolor="#FFFFFF" text="#000000">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>I highly recommand this article about how that problem
            can be solved in D</div>
          <div><a href="https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/" target="_blank">https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/</a><br>
          </div>
          <div><br>
          </div>
          <div>I don&#39;t know if implementers would be willing to move in
            this direction ?</div>
          <div><br>
          </div>
          <div>However, it&#39;s important to note that even if the compiler
            handle the module dependency itself</div>
          <div>it would also benefit from a fast module -&gt; file
            mapping, even more so than build systems.</div>
          <div><br>
          </div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <p> </p>
            </div>
            <div bgcolor="#FFFFFF" text="#000000">
              <p>Tom.<br>
              </p>
              <blockquote type="cite">
                <div class="m_7953253774571895280m_-7578053289813035424WordSection1">
                  <p class="MsoNormal"> </p>
                  <p class="MsoNormal"> </p>
                  <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
                    <div>
                      <div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
                        <p class="MsoNormal"><b>From:</b> <a class="m_7953253774571895280m_-7578053289813035424moz-txt-link-abbreviated" href="mailto:tooling-bounces@open-std.org" target="_blank">tooling-bounces@open-std.org</a>
                          <a class="m_7953253774571895280m_-7578053289813035424moz-txt-link-rfc2396E" href="mailto:tooling-bounces@open-std.org" target="_blank">&lt;tooling-bounces@open-std.org&gt;</a>
                          <b>On Behalf Of </b>Tom Honermann<br>
                          <b>Sent:</b> Thursday, January 10, 2019 9:27
                          PM<br>
                          <b>To:</b> WG21 Tooling Study Group SG15 <a class="m_7953253774571895280m_-7578053289813035424moz-txt-link-rfc2396E" href="mailto:tooling@open-std.org" target="_blank">&lt;tooling@open-std.org&gt;</a><br>
                          <b>Subject:</b> Re: [Tooling] Modules naming</p>
                      </div>
                    </div>
                    <p class="MsoNormal"> </p>
                    <div>
                      <p class="MsoNormal">On 1/10/19 5:17 PM, Ben Craig
                        wrote:</p>
                    </div>
                    <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
                      <p class="MsoNormal">Can you elaborate more on the
                        kinds of historical pains caused by tying a
                        #include directive to a file name?  I know of
                        issues with #pragma once, but that feels like a
                        distinct problem from file names.</p>
                      <p class="MsoNormal"> </p>
                      <p class="MsoNormal">&gt; This is based on decades
                        of experience caused by header files. </p>
                      <p class="MsoNormal">I think most of the
                        participants in wg21 have years, often decades
                        of experience with header files.  I know of
                        plenty of issues with the preprocessor, but I am
                        not yet aware of any major problems on the file
                        name front.  (ok, getting the right slashes can
                        be annoying… but it’s not a huge problem for me
                        personally).</p>
                      <p class="MsoNormal"> </p>
                      <p class="MsoNormal">I’m not a fan of the MANIFEST
                        / module map approach in general.  It requires
                        duplicating information that is already in the
                        source.  I get that it has the potential to
                        speed up builds, but I’d rather not have to
                        update another location when I add a new .cpp
                        file to my project.  Many build systems allow
                        for the user to make the tradeoff in whether
                        they will use a file system glob to enumerate
                        their source, or require the user to list the
                        source manually.  I usually fall into the file
                        system glob crowd.</p>
                    </blockquote>
                    <p>The manifest file could be generated (based on
                      information in source code) and usable by multiple
                      tools, IDEs, and build systems.  It need not be a
                      statically maintained file.  I like this approach
                      because it appropriately separates the steps of
                      identifying/building the module name/file map vs
                      using the module name/file map (most tools don&#39;t
                      want to be build systems).</p>
                    <p>Tom.</p>
                    <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
                      <p class="MsoNormal"> </p>
                      <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
                        <div>
                          <div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
                            <p class="MsoNormal"><b>From:</b> <a href="mailto:tooling-bounces@open-std.org" target="_blank">tooling-bounces@open-std.org</a>
                              <a href="mailto:tooling-bounces@open-std.org" target="_blank">&lt;tooling-bounces@open-std.org&gt;</a>
                              <b> On Behalf Of </b>Gabriel Dos Reis<br>
                              <b>Sent:</b> Thursday, January 10, 2019
                              3:15 PM<br>
                              <b>To:</b> WG21 Tooling Study Group SG15 <a href="mailto:tooling@open-std.org" target="_blank">&lt;tooling@open-std.org&gt;</a><br>
                              <b>Subject:</b> Re: [Tooling] Modules
                              naming</p>
                          </div>
                        </div>
                        <p class="MsoNormal"> </p>
                        <p class="MsoNormal">Microsoft strongly
                          encourages its developers and customers to NOT
                          tie a module name with the containing source
                          file of its interface.  This is based on
                          decades of experience caused by header files. 
                          I would rather see us move in the direction of
                          some sort of MANIFEST file that map modules to
                          source files and artifacts.</p>
                        <p class="MsoNormal"> </p>
                        <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
                          <div>
                            <div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
                              <p class="MsoNormal"><b>From:</b> <a href="mailto:tooling-bounces@open-std.org" target="_blank">tooling-bounces@open-std.org</a>
                                &lt;<a href="mailto:tooling-bounces@open-std.org" target="_blank">tooling-bounces@open-std.org</a>&gt;
                                <b>On Behalf Of </b>Corentin<br>
                                <b>Sent:</b> Thursday, January 10, 2019
                                6:53 AM<br>
                                <b>To:</b> WG21 Tooling Study Group SG15
                                &lt;<a href="mailto:tooling@open-std.org" target="_blank">tooling@open-std.org</a>&gt;<br>
                                <b>Subject:</b> [Tooling] Modules naming</p>
                            </div>
                          </div>
                          <p class="MsoNormal"> </p>
                          <div>
                            <p class="MsoNormal">Hello.</p>
                            <div>
                              <p class="MsoNormal">I would like to
                                suggest two modules related proposals
                                that I think SG15 should look at.</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">-<b> Compiler
                                  enforced mapping between module names
                                  and module interface file (resource)
                                  name. </b></p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">Currently, modules
                                interfaces can be declared in any file -
                                which makes dependency scanning more
                                tedious than it needs to be and have
                                performance implications</p>
                            </div>
                            <div>
                              <p class="MsoNormal">(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.</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">Tools ( ide, code
                                servers, indexers, refactoring) may also
                                greatly benefit from an easier way to
                                locate the source file which declares a
                                module.</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">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;</p>
                            </div>
                            <div>
                              <p class="MsoNormal">(The
                                standardese would mention <i>resource
                                  identifier</i> rather than filename)</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">- <b>A standing
                                  document giving guidelines for modules
                                  naming.</b></p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">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</p>
                            </div>
                            <div>
                              <p class="MsoNormal">that could be
                                partially enforced by build system
                                vendors.</p>
                            </div>
                            <div>
                              <p class="MsoNormal">Encouraging
                                consistency and uniqueness of module
                                identifiers across the industry is I
                                think a necessary step towards sane
                                package management.</p>
                            </div>
                            <div>
                              <p class="MsoNormal">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.</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">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.</p>
                            </div>
                            <div>
                              <div>
                                <p class="MsoNormal" style="margin-right:24.0pt;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt;vertical-align:baseline">
                                  <span style="font-size:10.0pt;font-family:Symbol"><span>·<span>        
                                      </span></span></span><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in">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.</span></b></p>
                                <p class="MsoNormal" style="margin-right:24.0pt;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt;vertical-align:baseline">
                                  <span style="font-size:10.0pt;font-family:Symbol"><span>·<span>        
                                      </span></span></span><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in">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.</span></b></p>
                                <p class="MsoNormal" style="margin-right:24.0pt;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt;vertical-align:baseline">
                                  <span style="font-size:10.0pt;font-family:Symbol"><span>·<span>        
                                      </span></span></span><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in">Do
                                      not export multiple top-level
                                      namespaces</span></b></p>
                                <p class="MsoNormal" style="margin-right:24.0pt;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt;vertical-align:baseline">
                                  <span style="font-size:10.0pt;font-family:Symbol"><span>·<span>        
                                      </span></span></span><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in">Do
                                      not export entities in the global
                                      namespace outside of the global
                                      module fragment.</span></b></p>
                                <p class="MsoNormal" style="margin-right:24.0pt;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt;vertical-align:baseline">
                                  <span style="font-size:10.0pt;font-family:Symbol"><span>·<span>        
                                      </span></span></span><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in">Organize
                                      modules hierarchically.</span></b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#42464c"> For
                                    example, if both modules </span><code><span style="font-size:10.0pt;color:#42464c;border:none windowtext 1.0pt;padding:0in">example.foo</span></code><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#42464c"> and </span><code><span style="font-size:10.0pt;color:#42464c;border:none windowtext 1.0pt;padding:0in">example.foo.bar</span></code><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#42464c"> exist
                                    as part of the public API of </span><code><span style="font-size:10.0pt;color:#42464c;border:none windowtext 1.0pt;padding:0in">example</span></code><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#42464c">, </span><code><span style="font-size:10.0pt;color:#42464c;border:none windowtext 1.0pt;padding:0in">example.foo</span></code><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#42464c"> should
                                    reexport </span><code><span style="font-size:10.0pt;color:#42464c;border:none windowtext 1.0pt;padding:0in">example.foo.bar</span></code></p>
                                <p class="MsoNormal" style="margin-right:24.0pt;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt;vertical-align:baseline">
                                  <span style="font-size:10.0pt;font-family:Symbol"><span>·<span>        
                                      </span></span></span><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in">Avoid
                                      common names such as </span></b><code><span style="font-size:10.0pt;color:#222324;border:none windowtext 1.0pt;padding:0in">util</span></code><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in"> and </span></b><code><span style="font-size:10.0pt;color:#222324;border:none windowtext 1.0pt;padding:0in">core</span></code><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in"> for
                                      module name prefix and top-level
                                      namespace names.</span></b></p>
                                <p class="MsoNormal" style="margin-right:24.0pt;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt;vertical-align:baseline">
                                  <span style="font-size:10.0pt;font-family:Symbol"><span>·<span>        
                                      </span></span></span><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in">Use
                                      lower-case module names</span></b></p>
                                <p class="MsoNormal" style="margin-right:24.0pt;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt;vertical-align:baseline">
                                  <span style="font-size:10.0pt;font-family:Symbol"><span>·<span>        
                                      </span></span></span><b><span style="font-size:7.5pt;font-family:&quot;Arial&quot;,sans-serif;color:#222324;border:none windowtext 1.0pt;padding:0in">Do
                                      not use characters outside of the
                                      basic source character set in
                                      module name identifiers.</span></b></p>
                              </div>
                            </div>
                            <div>
                              <p class="MsoNormal">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</p>
                            </div>
                            <div>
                              <p class="MsoNormal">while making possible
                                for example to design dependency
                                managers and build systems able to work
                                at the module level.</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">I&#39;d love to gather
                                feedback and opinions before going
                                further in that direction.</p>
                            </div>
                            <div>
                              <p class="MsoNormal">Thanks a lot!</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">Corentin</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal">PS: For a bit of
                                background, I talked about these issues
                                there</p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fcor3ntin.github.io-252Fposts-252Fmodules-5Fmapping-252F-26data-3D02-257C01-257Cgdr-2540microsoft.com-257C1139eb25a2ca43b5cb2e08d6770b6606-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636827288180838903-26sdata-3DRbCelyBe1YDW4eNJtYEgKkAeHGxvkhsYqzPk0wf3F58-253D-26reserved-3D0&amp;d=DwMGaQ&amp;c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&amp;r=y8mub81SfUi-UCZRX0Vl1g&amp;m=Yv6fjy4yWnfBkW_0m604prnwiQIO5K6DRLBHMjpiaxI&amp;s=v7Z40T9WgivvxWUJ6plSphOw4d8bdvfEz9NAqCruKwE&amp;e=" target="_blank">https://cor3ntin.github.io/posts/modules_mapping/</a></p>
                            </div>
                            <div>
                              <p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fcor3ntin.github.io-252Fposts-252Fmodules-5Fnaming-252F-26data-3D02-257C01-257Cgdr-2540microsoft.com-257C1139eb25a2ca43b5cb2e08d6770b6606-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636827288180838903-26sdata-3DtMhQa4ijeqUd2qxXV4loP47nU5NESRTKJLwZqe-252FI1fc-253D-26reserved-3D0&amp;d=DwMGaQ&amp;c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&amp;r=y8mub81SfUi-UCZRX0Vl1g&amp;m=Yv6fjy4yWnfBkW_0m604prnwiQIO5K6DRLBHMjpiaxI&amp;s=O9uUoT3QItO0vkb2QTG-EnXjsGfOiq7t93GgFz4YHx8&amp;e=" target="_blank">https://cor3ntin.github.io/posts/modules_naming/</a></p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                            <div>
                              <p class="MsoNormal"> </p>
                            </div>
                          </div>
                        </div>
                      </div>
                      <p class="MsoNormal"><br>
                        <br>
                      </p>
                      <pre>_______________________________________________</pre>
                      <pre>Tooling mailing list</pre>
                      <pre><a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a></pre>
                      <pre><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-2Dstd.org_mailman_listinfo_tooling&amp;d=DwMDaQ&amp;c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&amp;r=y8mub81SfUi-UCZRX0Vl1g&amp;m=_dusEGqwzSzglMFFwUFdPvzdZCb1dTUZ9DjjrQwHaUw&amp;s=o4EJMe6pKxUA_1edRMmVmbN3paM7ckt_7iDjgIveiwA&amp;e=" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a></pre>
                    </blockquote>
                    <p> </p>
                  </div>
                </div>
                <br>
                <fieldset class="m_7953253774571895280m_-7578053289813035424mimeAttachmentHeader"></fieldset>
                <pre class="m_7953253774571895280m_-7578053289813035424moz-quote-pre">_______________________________________________
Tooling mailing list
<a class="m_7953253774571895280m_-7578053289813035424moz-txt-link-abbreviated" href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a>
<a class="m_7953253774571895280m_-7578053289813035424moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/tooling" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a>
</pre>
              </blockquote>
              <p><br>
              </p>
            </div>
            _______________________________________________<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>
      <br>
      <fieldset class="m_7953253774571895280mimeAttachmentHeader"></fieldset>
      <pre class="m_7953253774571895280moz-quote-pre">_______________________________________________
Tooling mailing list
<a class="m_7953253774571895280moz-txt-link-abbreviated" href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a>
<a class="m_7953253774571895280moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/tooling" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </div>

_______________________________________________<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>