Make imports private by default

[kris]

Chris Miller wrote:
> On Thu, 13 Apr 2006 12:29:27 -0400, Bruno Medeiros  
> <brunodomedeirosATgmail at SPAM.com> 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.
>>>
>>
>> Totally agree.
>>
>> As for the consistency issue, it was said private imports by default  
>> where worth the small inconsistency (of everything else being 
>> public).  Actually I disagree with that at the premise level: I don't 
>> think it  would be an inconsistency at all. Imports are not members of 
>> the module,  as they do not even define a new entity. They are not a 
>> "part of" the  module, they are more like a characteristic of it.
>> Further indication is that there is no "package import". And even  
>> "public import", would it be of any significant use?
>>
>> (Of course one could think of imports as the definition of a set of  
>> aliases, but really, I would think that's an unadequate and contrived  
>> conceptualization)
>>
> 
> Good point. Perhaps the current private import should be the default, 
> and  to achieve the current public import, something else could be used, 
> such  as "static import" ?
> 
> Since the majority of imports are private, and even some public ones  
> should have been private, I don't think this change would be difficult.
> 
> The most common case would then be:
>    * Default, logical choice;
>    * Easier to type;
>    * Better looking code;


I'm not so sure that makes sense :)

Yes, there's a long standing problem with symbol/namespace collisions 
and it would be great to resolve that.

Bruno suggests that imports are nothing more than a "characteristic" of 
a module ~ that makes sense, but then couldn't one also think of a class 
contained therein as a characteristic too? Especially a class that is 
intended /not/ to be exposed outside of the module (which we apparently 
cannot hide via package or private; right?).

In order to make D easy to learn and use, surely consistency in usage 
should be a priority? D kinda has that right now in this particular 
area, in that everything is public by default. It would also be fine, 
IMO, if everything were private by default :)

Either way, the symbol/namespace collision thing has been thorny for a 
long time. I'm not so sure that would even be resolved properly by 
making imports private anyway -- it may mask the problem a little.

- Kris