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

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

--- Comment #12 from Martin Nowak  ---
Weird, only seems to fail for top-level packages, but not for nested `std.pkg`
and `std.pkg.mod` cases.

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||an...@s-e-a-p.de

--- Comment #11 from Vladimir Panteleev  ---
*** Issue 17683 has been marked as a duplicate of this issue. ***

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=8855

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

--- Comment #10 from cpierrot...@gmail.com ---
I have found out that renamed imports in the can be used as a workaround:

test/package.d
---
module test;
import mod = test.mod;
---

test/mod.d
---
module test.mod;
import std.stdio;
void func(){writeln("hello world");}
---
main.d
---
import test;
import test.mod;

void main() {
   func();
}
---

compiled and worked as expected (prints "hello world")

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

Maksim Zholudev  changed:

   What|Removed |Added

 CC||maxim...@gmail.com

--- Comment #9 from Maksim Zholudev  ---
A fragment of `dub test` output for my main project:

Excluding package.d file from test due to
https://issues.dlang.org/show_bug.cgi?id=11847
Excluding package.d file from test due to
https://issues.dlang.org/show_bug.cgi?id=11847
Excluding package.d file from test due to
https://issues.dlang.org/show_bug.cgi?id=11847
Excluding package.d file from test due to
https://issues.dlang.org/show_bug.cgi?id=11847
Excluding package.d file from test due to
https://issues.dlang.org/show_bug.cgi?id=11847
Excluding package.d file from test due to
https://issues.dlang.org/show_bug.cgi?id=11847
Excluding package.d file from test due to
https://issues.dlang.org/show_bug.cgi?id=11847


If this is "by design" then
1) it should be justified
2) it should be documented
3) tools should stop complaining about it (or stop doing this with so many
identical lines)

Otherwise it is a bug.

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

Nick Sabalausky cbkbbej...@mailinator.com changed:

   What|Removed |Added

 CC||cbkbbej...@mailinator.com

--- Comment #8 from Nick Sabalausky cbkbbej...@mailinator.com ---
I've hit this problem too, and it's a pain in the ass. It makes it nearly
impossible to resolve a symbol ambiguity whenever a package.d is involved. It
effectively destroys the ability for package.d to do it's primary intended
job: Let module authors break up a module without breaking user code. This
needs fixed.

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

sigod sigod.m...@gmail.com changed:

   What|Removed |Added

 CC||sigod.m...@gmail.com

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #5 from Martin Nowak c...@dawg.eu ---
I agree with Söhnke here, it should still be possible to import submodules and
it should also be possible to use fully qualified names.

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com

--- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com ---
I also agree with Sönke. There should be no difference between publicly
imported modules in package.d and publicly imported modules in any other
module. All package.d should be doing is making it so that when you import the
package, you import package.d instead. It shouldn't have any other effects.

import test;
import test.mod;

should work just as well as

import std.array;
import std.range;

does. std.array.uninitializedArray doesn't suddenly stop working just because
you also imported std.range, which publicly imports std.array.

--

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11847

--- Comment #7 from Jonathan M Davis jmdavisp...@gmx.com ---
Also, keep in mind that the whole reason to add package.d to the language in
the first place was to be able to break up a module into a package, in which
case, it's intended as a migration path and not necessarily as something
permanent, so making it so that importing a package conflicts with importing
its individual modules is very likely to cause problems - especially if new
modules with code that wasn't in the original module that was split are added
after it's been split (since they likely wouldn't be publicly imported in the
package.d file, because that's unnecessary for migration).

--

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

[d-bugmail]

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



--- Comment #2 from S�nke Ludwig slud...@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: ---

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

[d-bugmail]

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



--- Comment #3 from Kenji Hara k.hara...@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: ---

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

[d-bugmail]

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: ---

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

[d-bugmail]

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



--- Comment #1 from Kenji Hara k.hara...@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: ---