<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Feb 2019 at 05:01 Isabella Muerte &lt;<a href="mailto:imuerte@pm.me">imuerte@pm.me</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>If each implementation does something different regarding modules and filenames, then C++ will die a slow painful death. If we can&#39;t have implementations agree on a singular thing to do, that is going to fragment the community further, cause headaches, and waste hundreds of hours of developer time trying to get everything to work the same. I do not trust vendors to do the right thing and work together outside of the standard.<br></div></blockquote><div><br></div><div>+1<br></div><div><br></div><div>Also, when you say &quot;your implementation&quot; that&#39;s a very fuzzy thing when talking about modules.</div><div>There is a build system, a compiler, a package manager, multiple tools and they all need to agree on the same conventions for anything to work.</div><div><br></div><div><div>One of C++ strength is to be portable across a wide variety of systems.</div><div>Alas, tools are not portable and often not compatible.</div></div><div><br></div><div>Lack of common ground rules is what makes consuming libraries and reusing code in C++</div><div>time-consuming (and therefore costly).</div><div>There is nothing in the language per-say that precludes good dependency management,</div><div>but because every vendor has to come up with their own solutions to the same problems,</div><div>everybody needs to support non-standard, slightly broken behaviors.</div><div><br></div><div>I agree that in general, most of the challenges that tool face fall outside of the scope of the IS.</div><div>In this particular case, however, it doesn&#39;t seem difficult to set these rules.</div><div><br></div><div>And, there would be no loss in expressiveness.</div><div>Indeed, what is the added value of not requiring some deterministic mapping?</div><div>What do I gain in having &quot;export module foo&quot; in a resource identified by bar?</div><div><br></div><div>(Note that we do not want module interface units to be necessarily files just that they be identified by the name of the module they define)</div><div><br></div><div>Freedom of implementation only makes sense if the added value it provides is greater than its cost.</div><div>Ecosystems need rules to thrive.</div><div><br></div><div>Sure, ultimately people would probably find workarounds and hack and build systems would support multiple compiler implementations.<br></div><div>At what cost? In how many years?</div><div><br></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>Furthermore, while C# permits names and modules not being the same, this isn&#39;t as much of an issue given that a module is also a namespace (which is orthogonal to modules in C++), they have partial classes (which we do not), and they don&#39;t have separate interface and implementation files. I reckon if C# had to deal with some of the issues we are, it would be less popular. 😉<br></div><div class="m_3200632677825109801protonmail_signature_block m_3200632677825109801protonmail_signature_block-empty"><div class="m_3200632677825109801protonmail_signature_block-user m_3200632677825109801protonmail_signature_block-empty"><br></div><div class="m_3200632677825109801protonmail_signature_block-proton m_3200632677825109801protonmail_signature_block-empty"><br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Sunday, February 3, 2019 7:41 PM, Gabriel Dos Reis &lt;<a href="mailto:gdr@microsoft.com" target="_blank">gdr@microsoft.com</a>&gt; wrote:<br></div><div> <br></div><blockquote type="cite" class="m_3200632677825109801protonmail_quote"><div><ul style="margin-top:0in" type="disc"><li style="margin-left:0in">We have a lot of experience in other languages for deterministic and direct  name -&gt; file mapping, very little for having the module name solely in the source.<br></li></ul><p> <br></p></div></blockquote><blockquote type="cite" class="m_3200632677825109801protonmail_quote"><div><p>I keep reading this.  The opposite is just true as well.  For example, there are lot of experience with C# out there and their productivity hasn’t gotten down because of it.<br></p><p> <br></p><p>Lost in all this brouhaha is the fact that the IS does not preclude a trivial mapping: your implementation will document what it wants.<br></p><p> <br></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></p><div><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></div><div> <b>Sent:</b> Sunday, February 3, 2019 6:00 PM<br></div><div> <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></div><div> <b>Subject:</b> Re: [Tooling] SG15 Why do we need module name to file name mapping<br></div><p></p></div></div></div></div></blockquote><blockquote type="cite" class="m_3200632677825109801protonmail_quote"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><p> <br></p><div><p> <br></p><div><p>We don&#39;t need it and a lot of us believe we need to not have it.<br></p></div><div><p>The price for this level of indirection, as you say is quite high on tooling. the benefits un-existant.<br></p></div><div><p> <br></p></div><div><p>The evolution working group and the authors of the module proposal seem afraid to over specify - while SG-15 thinks<br></p></div><div><p>leaving things as they are will lead for decades of pain. At least, I certainly think so.<br></p></div><div><p> <br></p></div><div><p>We have a lot of experience in other languages for deterministic and direct  name -&gt; file mapping, very little for having the module name solely in the source.<br></p></div><div><p> <br></p></div><div><p> <br></p></div><div><p>As for name collision... It&#39;s not a problem. It would even be a good thing to make sure not to have duplicated file names: <br></p></div><div><p>Module identifier needs to be unique in a program, so asking the same of files is reasonable.<br></p></div><div><p> <br></p></div><div><p> <br></p></div><div><p> <br></p></div><div><p> <br></p></div></div><p> <br></p><div><div><p>On Mon, 4 Feb 2019 at 02:20 Scott Wardle &lt;<a href="mailto:swardle@gmail.com" target="_blank">swardle@gmail.com</a>&gt; wrote:<br></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p></p><div>Hi all, <br></div><div> <br></div><div> I have been looking for some information why do we need a level of indirection from module name to module interface file name.  Why are modules names need a different system then header names. <br></div><div> <br></div><div> I have hear that Microsoft was having some problems with name collision. Is there more concrete information about the problem that Microsoft or other companies were having? <br></div><div> <br></div><div> If you have a name collision today with headers we would just make another library that wraps one of the two colliding headers. I name the public header of this new library something different and problem solved. <br></div><div> <br></div><div> So I don’t understand why are we paying for this level of indirection but I probably just don’t understand the problem. <br></div><div> <br></div><div> Scott <br></div><div> _______________________________________________<br></div><div> Tooling mailing list<br></div><div> <a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br></div><div> <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&amp;data=02%7C01%7Cgdr%40microsoft.com%7C3adf39f0c683427fb84108d68a447a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636848424056005598&amp;sdata=NzK37Ir7HzGpduYGXcUZtsC5u8N0DzOVxpdWUnIsIU0%3D&amp;reserved=0" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br></div><p></p></blockquote></div></div></div></blockquote><div><br></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>