Are public/private imports implemented?

[Bill Baxter]

Tyro[a.c.edwards] wrote:
> Bill Baxter さんは書きました:
>> Tyro[a.c.edwards] wrote:
>>> Ary Borenszweig ????????:
>>>> Again, testing some Descent semantic code, I was getting errors on 
>>>> undefined functions.
>>>>
>>>> ---
>>>> module one;
>>>>
>>>> import two;
>>>>
>>>> void foo() {
>>>>     char[] srcfilename = std.path.join("one", "two");
>>>> }
>>>> ---
>>>>
>>>> ---
>>>> module two;
>>>>
>>>> import std.path; // same with "private import std.path;"
>>>> ---
>>>>
>>>> I was getting an error on "std.path.join", because since the import 
>>>> on module two is private, join is not visible. But DMD seems to 
>>>> compile it without problems. What's the truth about imports?
>>>
>>> module imports are private by default. This means that since you 
>>> "privately" imported std.path into module two, then the entire 
>>> content of the std.path module becomes visible to module two, and 
>>> module two alone. As a result std.path is not defined in module one. 
>>> In order for it to be defined, you would also need to import std.path 
>>> in module one or do "public import std.path;" in module two.
>>
>> The truth seems to be more that fully qualified names are always made 
>> public.
>> http://d.puremagic.com/issues/show_bug.cgi?id=314.
>>
>> --bb
> 
> I thought I ran across that bug a few weeks back when I bought and 
> started reading "Learn to Tango with D" but somehow managed to convince 
> myself that it didn't exist.
> 

It's going to bite me hard if it ever gets fixed.  For imports I'm not 
using extensively in a module I tend to use fully qualified names and 
take a "shoot first; ask questions later" approach.  So for instance I'm 
sure I have *lots* of std.string.format()'s in modules that never 
imported std.string which just happen to work because some module 
somewhere that I imported does.

--bb