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;
Comment #1 by bearophile_hugs — 2014-03-07T13:06:25Z
(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).
Comment #2 by jbinero — 2014-03-07T13:10:07Z
(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.
Comment #3 by bearophile_hugs — 2014-03-07T13:24:32Z
(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?
Comment #4 by jbinero — 2014-03-07T13:26:21Z
(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.
Comment #5 by dlang-bugzilla — 2014-03-07T13:28:17Z
How is this different from a package.d file?
Comment #6 by jbinero — 2014-03-07T13:33:17Z
(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.
Comment #7 by nick — 2019-01-06T13:00:07Z
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.
Comment #8 by razvan.nitu1305 — 2022-08-22T12:08:37Z
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.