It should be allowed for renaming the same import twice, with the same name. // This should be possible private import gtk = gtk.Application; private import gtk = gtk.Window;
(In reply to comment #0) > It should be allowed for renaming the same import twice, with the same name. > > // This should be possible > private import gtk = gtk.Application; > private import gtk = gtk.Window; Please list what are the advantages an disadvantages of this proposal. (At first sight I don't like it, but perhaps I am wrong).
(In reply to comment #1) > Please list what are the advantages an disadvantages of this proposal. (At > first sight I don't like it, but perhaps I am wrong). The main advantage is that when you have libraries like the GtkD which I used in the first post, you can put them all in one namespace. This way you don't get the redundancy of specifying the exact module name for every call to a function, but you still keep your code clean and maintainable by specifying what library a certain class/struct/object belongs to.
(In reply to comment #2) > (In reply to comment #1) > > Please list what are the advantages an disadvantages of this proposal. (At > > first sight I don't like it, but perhaps I am wrong). > > The main advantage is that when you have libraries like the GtkD which I used > in the first post, you can put them all in one namespace. > > This way you don't get the redundancy of specifying the exact module name for > every call to a function, but you still keep your code clean and maintainable > by specifying what library a certain class/struct/object belongs to. What are the disadvantages?
(In reply to comment #3) > (In reply to comment #2) > > The main advantage is that when you have libraries like the GtkD which I used > > in the first post, you can put them all in one namespace. > > > > This way you don't get the redundancy of specifying the exact module name for > > every call to a function, but you still keep your code clean and maintainable > > by specifying what library a certain class/struct/object belongs to. > > What are the disadvantages? I can't really think of any. Obviously it can cause conflicts if you have two matching symbols and you put them in the same module/namespace; but conflicts are already possible as-is, and should be avoided.
How is this different from a package.d file?
(In reply to comment #5) > How is this different from a package.d file? You mean having a separate module publicly importing all the required modules? The difference would be that not a separate module would be needed for every different set of includes possible. Obviously you could make one file simply importing everything, but that'd just be an over-kill. When a module only uses 2 or 3 modules it's not worth importing every single one of them.
This could be implemented with a struct template: alias gtk = MergeImports!"gtk.Application, gtk.Window"; The struct would expose the listed modules' members as aliased struct members. I think this should be closed as WONTFIX, because it adds complexity for the user when analysing modules for a case which might not be common enough, and can be done as above.
I don't really see any benefit in allowing this sort of behavior. If you have only 2-3 modules that you are importing you can either just put those imports top-level or just use them selectively inside the functions that require them. I think that D already provides plenty of options for such scenarios, therefore it is not needed to further complicate the language implementation to allow such a narrow use case. If needed, the workaround presented by Nick is applicable.