On Thu, Jan 10, 2019 at 6:53 AM Corentin <email@example.com> wrote:
> I would like to suggest two modules related proposals that I think SG15 should look at.
> - Compiler enforced mapping between module names and module interface file (resource) name.
Why does SG15 need to do this, versus someone implementing it in an
open-source toolchain, trying it out, and bringing what using it
taught them to SG15?
> Currently, modules interfaces can be declared in any file - which makes dependency scanning more tedious than it needs to be and have performance implications
> (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.
> Tools ( ide, code servers, indexers, refactoring) may also greatly benefit from an easier way to locate the source file which declares a module.
> 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>
> (The standardese would mention resource identifier rather than filename)
> - A standing document giving guidelines for modules naming.
> 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
> that could be partially enforced by build system vendors.
> Encouraging consistency and uniqueness of module identifiers across the industry is I think a necessary step towards sane package management.
> 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.
> 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.
> 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.
> 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.
> Do not export multiple top-level namespaces
> Do not export entities in the global namespace outside of the global module fragment.
> 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
> Avoid common names such as util and core for module name prefix and top-level namespace names.
> Use lower-case module names
> Do not use characters outside of the basic source character set in module name identifiers.
> 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
> while making possible for example to design dependency managers and build systems able to work at the module level.
> I'd love to gather feedback and opinions before going further in that direction.
> Thanks a lot!
> PS: For a bit of background, I talked about these issues there
> Tooling mailing list
Tooling mailing list