<div dir="ltr">On Thu, Oct 31, 2013 at 6:02 PM, Doug Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  Sorry for the slow reply, but it seems like a net loss to generalize the simple identifier-based module naming scheme to full string literals, because we're making the mental model more complex ("when do I use / in a string literal vs. a submodule?"). The automatic mapping from header names to module names is a convenience that helps one avoid writing module maps for everything. When the automatic mapping "fails" because the header name isn't an identifier, I think it's reasonable to either (1) require that the user provide an identifier to name the (sub)module corresponding to that header, or (2) sanitize the name in some way to make it an identifier. In particular, I don't think it's important at all for the unmodified header name to be namable from an (@)import declaration, since one can continue using #include until a suitable name is chosen for the (sub)module.<br>
</blockquote><div><br></div><div>I think the most interesting feature this would enable is to automatically generate good diagnostics for layering violations when implicit modules are used via the build system (we'd still #include everything in that case). Imagine adding something to CMake that automatically generates module maps for each cmake add_library call, including all the headers in the sources of that library, thus speeding up incremental compiles without needing any changes to the code if it already complies with the unwritten rules of sane C++ code.</div>
<div><br></div><div>Of course we could map library names to C++ identifiers on the cmake level, but then the diagnostics that mention modules (for example when pointing out layering violations due to private headers) would have names with no corresponding "real" entity, thus being confusing to users.</div>
</div></div></div>