https://d.puremagic.com/issues/show_bug.cgi?id=11847
--- Comment #4 from S�nke Ludwig <slud...@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: -------