https://issues.dlang.org/show_bug.cgi?id=3603
John Hall <john.michael.h...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |john.michael.h...@gmail.com --- Comment #4 from John Hall <john.michael.h...@gmail.com> --- Multiple named imports also discussed here: https://forum.dlang.org/thread/hashhduapewjhqmwh...@forum.dlang.org ------------------------------------ With respect to: > import really.very.deeply.nested.package: module1, module2, module3; or > import std: stdio, algorithm, range, array; consider: -----[ foo\package.d ]----- module foo; public import foo.bar; public import foo.baz; public import foo.bazinga; -----[ foo\bar.d ]----- module foo.bar; void bar() { }; -----[ foo\baz.d ]----- module foo.baz; void baz() { }; -----[ foo\bazinga.d ]----- module foo.bazinga; void bazinga() { }; ------------------------------------ Under your suggestion, if you: import foo : bar, baz; how does the compiler know to import the functions or the modules? Under the current approach, it's not an issue since the selective import only brings in the symbols. ------------------------------------ I think the alternative would be to introduce a new syntax for selective module imports, where import foo :: bar, baz; causes the modules bar and baz to be imported, but not bazinga. This would be equivalent to import foo.bar; import foo.baz; Static imports should follow a similar pattern. It gets a little more complicated with re-named imports where something like import barbaz = foo :: bar, baz; may be possible. This functionality currently requires a more challenging workaround, discussed in the above thread, as it is an error to write import barbaz = foo.bar; import barbaz = foo.baz; because barbaz is assigned to two things. This functionality may also mix with the current functionality for selective imports, such as import foo :: bar, baz : bar, baz; though this depends on the implementation details, for instance, the following would not compile import foo.bar : bar, baz; import foo.baz : bar, baz; so the compiler would need to do something like search foo.bar for either bar or baz and only import them if they are there, cross off what is found, then search foo.baz for the remainder, and give an error if something isn't found. In addition, one could have a re-named version import barbaz = foo :: bar, baz : bar, baz; which should follow from getting the above to work. Finally, one point I didn't address specifically was about the deeply nested modules that the OP refers to. The OPs example of > import really.very.deeply.nested.package: module1, module2, module3; would become > import really.very.deeply.nested.package :: module1, module2, module3; However, it also would be convenient to be able to write > import really :: module1, module2, module3; assuming the module names are unique. I am not sure if this is possible. --