The "package.d" feature behaves strangely. It seems that the root of the issues is the way fully-qualified names work when using package.d. Since there is no proper documentation (only DIP37 and the changelog), there is no way to know wether the current behvior is a bug or not.
Here are two examples showing what is perceived as improper (or, at least, suspicious) behaviour:
EXAMPLE 1: Trying to simply replace the old "all.d" idiom with package.d doesn't work out-of-the-box:
Originally, I had something like this:
// mylib/util.d:
module mylib.util;
class Foo { }
// mylib/all.d:
module mylib.all;
public import mylib.util;
// main.d:
import mylib.all;
void main()
{
auto f = new mylib.util.Foo;
}
And this used to work. Now, I added a new file:
// package.d
module mylib;
public import mylib.util;
And changed the 'import' in the main one:
// main.d
import mylib;
void main()
{
auto f = new mylib.util.Foo;
}
Now, the compiler complains:
main.d(5): Error: undefined identifier 'util'
main.d(5): Error: mylib.util.Foo is used as a type
[Using mylib.Foo instead of mylib.util.Foo works -- which makes sense when thnking about the use case of using package.d to split a large package into smaller ones. ]
---------------------
EXAMPLE 2: Inconsistency with fully-qualified names
// mylib/util.d
module mylib.util;
class Foo { }
// mylib/package.d
module mylib;
public import mylib.util;
// main.d
import std.stdio;
import mylib;
void main()
{
auto f = new mylib.Foo;
writefln("%s", f.classinfo.name);
}
This prints 'mylib.util.Foo'. So far so good, that's the name I originally expected.
Then I try to instantiate a 'Foo' using this very fully-qualified name the compiler told me:
auto f = new mylib.util.Foo;
And DMD doesn't like it anymore:
main.d(6): Error: undefined identifier 'util'
main.d(6): Error: mylib.util.Foo is used as a type
[This looks very much like a bug for me. The name given by classinfo.name should be usable to instantiate a class, shouldn't it? ]
Comment #1 by lmb — 2014-01-27T15:03:25Z
For the record: the submitted examples were tested with DMD 2.064, under Linux/x86_64.
Comment #2 by nick — 2019-01-07T17:12:00Z
(In reply to Leandro Motta Barros from comment #0)
> there is no proper documentation (only DIP37 and the changelog),
It is now documented:
https://dlang.org/spec/module.html#package-module
> // package.d
> module mylib;
> public import mylib.util;
Is package.d under `mylib/`?
Comment #3 by robert.schadek — 2024-12-13T18:16:25Z