[Issue 11847] Importing "package.d" module causes qualified name lookup to fail for sub modules

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Jan 5 01:56:07 PST 2014


https://d.puremagic.com/issues/show_bug.cgi?id=11847



--- Comment #4 from Sönke Ludwig <sludwig at outerproduct.org> 2014-01-05 01:55:42 PST ---
I think this is actually totally unacceptable and a *serious* design flaw. What
this means is that it is now impossible to reference any sub module of "test"
as soon as "test" is imported. This seems to be based on the assumption that
"package.d" modules always import all modules of their package, which is just
wrong. There are many possible reasons why it would exclude certain modules.

This also means that it is now impossible to disambiguate conflicting symbols
when one of them is in such a sub module. This completely breaks the module
system.

A real world example, where it is important to be able to handle this cleanly,
is an automatically generated function that iterates over all modules of a
project (It's a unit test runner that runs all unit tests for each module). It
contains code similar this:

---
static import test;
static import test.mod;

alias AllModules = TypeTuple!(test, test.mod); // error

main() {
    foreach (mod; AllModules) ...
}
---

The only half reasonable thing that could be done there is to generally ignore
all "package.d" modules. And that is based on the assumption that "package.d"
modules *only* import all sub modules and have no own declarations, which, in
general, again is wrong.

Also, if there is no NG or conference discussion that I didn't see, there is no
sign in the original DIP that this issue was even considered before
implementing it. In this case, calling it by design may be a slight
exaggeration.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list