Make imports private by default

[clayasaurus]

clayasaurus wrote:
> Hasan Aljudy wrote:
>> Don Clugston wrote:
>>> Hasan Aljudy wrote:
>>>
>>>> Frank Benoit wrote:
>>>>
>>>>> There was a posting of Tyro
>>>>> http://www.digitalmars.com/d/archives/digitalmars/D/11081.html
>>>>>
>>>>> Most ppl seconded that.
>>>>>
>>>>> The problem is, that D does not work if you use non-private imports 
>>>>> all
>>>>> the time. Suddenly there are conflicts.
>>>>>
>>>>> A public import make the imported module part of this modules 
>>>>> interface.
>>>>> This can (and should) be made public explicitely.
>>>>>
>>>>
>>>> I never understood why people use private imports .. just what the 
>>>> hell is the point?
>>>> Please give real, concrete examples, not just theories/talk.
>>>> "Clogging up the namespace" doesn't say anything meaningful to me.
>>>
>>>
>>> If module foo publicly imports std.date, then any module which 
>>> imports foo cannot use std.string.format without colliding with 
>>> std.date.format.
>>> This has bitten me several times already.
>>
>> OK, this seems to be a valid problem, however, even if imports become 
>> private by default, there's nothing stopping foo from publicly 
>> importing std.date and std.string at the same time.
>>
> 
> But at least the error is in the file the dmd compiler says it is, the 
> error for the above problem will be almost impossible for a maintainer 
> to find in a large project.
> 

Nevermind, I thought you were trying to illustrate a different problem :-/