I just made the discovery that putting a D source file named "d" in a
directory named "a.b.c" with a module declaration like:
module a.b.c.d;
works as expected (can be imported via import a.b.c.d;). This is
actually pretty cool and useful, because there are times where you end up having a directory containing a single directory containing a single directory, ..., just because of the module path. Having to traverse three folders just to get to the source code could easily be avoided if this was actually an official feature.
At the moment this only works if you provide the imported module at the command line, but not if you only provide -I and just compile with -c:
dmd -c main.d
main.d(1): Error: module t is in file 'a/b/c/d.d' which cannot be read
import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import
while this is fine:
dmd main.d a.b.c/d.d
I think it might be a good idea having the compiler fallback to a folder a.b.c if it exists (or a.b). It could simply prefer a/b/c over a.b/c over a.b.c. In practice only one of them should exist anyway, so the compiler could also just issue an error if ambiguous.
Comment #1 by bearophile_hugs — 2013-03-08T04:31:15Z
What are the long-term risks of introducing this? Is this a clean feature, or an unclean hack that will cause troubles later?
Comment #2 by jfanatiker — 2013-03-08T09:04:24Z
(In reply to comment #1)
> What are the long-term risks of introducing this? Is this a clean feature, or
> an unclean hack that will cause troubles later?
That is the question. I don't see any problems, but if someone does please post them here.
Comment #3 by issues.dlang — 2013-03-08T09:09:03Z
Modules correlate to files and packages correlate to folders, and the relationship is 1-to-1. That's the design. It's straightforward and simple. This very much goes against that.
And it would be even better IMHO if it weren't legal to have modules which didn't have a module declaration (since you pretty much always have to have it anyway, as it's required if the module is in a package), and I think that allowing for modules to have different names than their file names was a mistake, as it adds extra complication and confusion for no benefit IMHO. But I rather doubt that either of those will change at this point.
Comment #4 by bearophile_hugs — 2013-03-08T10:31:08Z
(In reply to comment #3)
> Modules correlate to files and packages correlate to folders, and the
> relationship is 1-to-1. That's the design. It's straightforward and simple.
> This very much goes against that.
I agree.
Generally I am for keeping the language tidy. Because most times you don't do this, later something comes back to bite your butt.
----------------------
The following things are mostly off topic for this Bugzilla entry:
> And it would be even better IMHO if it weren't legal to have modules which
> didn't have a module declaration (since you pretty much always have to have it
> anyway, as it's required if the module is in a package),
If your program is composed by only 1 module (like when you write very short programs), then in my opinion it's not necessary to give it a module declaration.
The module declaration is "infrastructure". Infrastructure is very useful when programs grow bigger, but being forced to put infrastructure when you don't need it, that is in very small programs, is a waste of energy.
> and I think that allowing for modules to have different names than their
> file names was a mistake, as it adds extra complication and confusion
I agree.
> for no benefit IMHO.
Walter has said there is some benefit (but I don't remember what). Even if this is true, then I think such cases are special. And it's generally bad to break a tidy convention for some special cases. If those cases are so important then they should have a special "syntax", leaving the much more general case clean of 1:1 between module name and file name.
Comment #5 by nick — 2019-01-06T13:18:43Z
> there are times where you end up having a directory containing a single
> directory containing a single directory, ..., just because of the module path
This is a valid reason, but if we want to support this I think it needs clear identifying syntax, something like `import "a.b.c".d` (although this doesn't work for fully qualifying symbols in code). Adding more module location ambiguity harms understandability (even with errors on conflicts), and this situation seems quite niche. I think it should be an error for a package directory name not to be a valid single identifier. Suggest we close as WONTFIX.
Comment #6 by robert.schadek — 2024-12-13T18:04:31Z