package.d behavior

[Lemonfiend]

That at least one more user here :)

package.d really deserves more than just a changelog entry. Like 
a proper mention in the docs, with a description of its expected 
behaviour.
Then users would at least be able to determine whether something 
was a bug or working as intended.

On Thursday, 23 January 2014 at 11:43:07 UTC, Leandro Motta 
Barros wrote:
> Hi,
>
> Do anyone has any feedback about his issue? I (and at least one 
> more user)
> believe that the "package.d" feature behaves strangely (please, 
> see the
> examples in my original post).
>
> Thanks a lot,
>
> LMB
>
> PS: I am not a big fan of "bump" posts, but I believe this 
> message may have
> been ignored given some forum issues last week -- when it 
> appeared, it was
> already buried under several more recent messages.
>
>
> On Sat, Jan 18, 2014 at 10:32 AM, Leandro Motta Barros 
> <lmb at stackedboxes.org
>> wrote:
>
>> Hello!
>>
>> About a month ago I asked in D.learn about the expected 
>> behavior of the
>> new package.d feature [1]. I got a cuple of responses, but not 
>> really
>> answers. Today I noticed a second post [2] with similar but 
>> still
>> unanswered questions. So it seemed like a good idea to bring 
>> the discussion
>> to the main forum.
>>
>> Basically, I seems that the root of the issues we are facing 
>> is the way
>> fully-qualified names work when using package.d (I have added 
>> some examples
>> below showing what I mean).
>>
>> We also felt that the feature is under-documented (DIP37 and 
>> the changelog
>> seem to be the only places where the feature is discussed, and 
>> some
>> important details are missing.) I was actually about to fill 
>> bug a report
>> about the behavior, but I ended up not doing so because I 
>> couldn't find out
>> what the expected behavior is.
>>
>> So, any feedback and clarifications are welcome!
>>
>> Thanks for the attention, and keep up the great work :-)
>>
>> LMB
>>
>> [1]
>> http://forum.dlang.org/thread/CANY+vSMzLJ5ehKGW8cE1KkoMOm7x3roKmVgMjyCqZrwD9aLO9w@mail.gmail.com
>> [2] 
>> http://forum.dlang.org/thread/eeaslvjwenkygwszqznc@forum.dlang.org
>>
>>
>> -----------------------
>>
>> 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.nameshould be usable to instantiate a class, 
>> shouldn't it? ]