digitalmars.D.bugs - [Issue 12014] New: package.d behaves suspiciously (and there are no docs)
- d-bugmail puremagic.com (80/80) Jan 27 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12014
- d-bugmail puremagic.com (7/7) Jan 27 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12014
https://d.puremagic.com/issues/show_bug.cgi?id=12014 Summary: package.d behaves suspiciously (and there are no docs) Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: lmb stackedboxes.org 14:56:47 PST --- 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? ] -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 27 2014
https://d.puremagic.com/issues/show_bug.cgi?id=12014 15:03:25 PST --- For the record: the submitted examples were tested with DMD 2.064, under Linux/x86_64. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 27 2014