www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11847] New: Importing "package.d" module causes qualified name lookup to fail for sub modules

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11847

           Summary: Importing "package.d" module causes qualified name
                    lookup to fail for sub modules
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: sludwig outerproduct.org


--- Comment #0 from Sönke Ludwig <sludwig outerproduct.org> 2013-12-30 13:49:45
PST ---
The following errors out with "main.d(5): Error: undefined identifier 'mod'":

main.d
---
import test;
import test.mod;

void main() {
    test.mod.func();
}
---

test/package.d
---
module test;
---

test/mod.d
---
module test.mod;

void func() {}
---

Seems like ".test" now refers to the module instead of the package and thus
there is no sub module "mod". Tested on DMD 2.064.2.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 30 2013
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11847



--- Comment #1 from Kenji Hara <k.hara.pg gmail.com> 2014-01-04 23:24:21 PST ---
(In reply to comment #0)
 The following errors out with "main.d(5): Error: undefined identifier 'mod'":
 
 main.d
 ---
 import test;
 import test.mod;
 
 void main() {
     test.mod.func();
 }
 ---

Currently this is by design. If you use fully qualified name that starts with "test.", test/package.d is always preferred to avoid ambiguity. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 04 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11847



--- Comment #2 from Sönke Ludwig <sludwig outerproduct.org> 2014-01-05 01:08:27
PST ---
So how would I specify a qualified name in test.mod?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 05 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11847



--- Comment #3 from Kenji Hara <k.hara.pg gmail.com> 2014-01-05 01:19:53 PST ---
(In reply to comment #2)
 So how would I specify a qualified name in test.mod?

There's no way, if you import both test/package.d and test/mod.d. I think it is legitimate limitation of the new package.d feature. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 05 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11847



--- Comment #4 from Sönke Ludwig <sludwig 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: -------
Jan 05 2014