On Thu, Jan 10, 2019 at 6:53 AM Corentin <corentin.jabot_at_[hidden]> wrote:
>
> Hello.
> 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!
>
> Corentin
>
> PS: For a bit of background, I talked about these issues there
>
> https://cor3ntin.github.io/posts/modules_mapping/
> https://cor3ntin.github.io/posts/modules_naming/
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling