Import concerns revisited

[Dave]

Bruno Medeiros wrote:
> Walter Bright wrote:
>>
>>> OT: if you'll be changing the import system, _PLEASE_ make private 
>>> imports the default.
>>
>> It's too late for that, sorry. Also, everything else in D is public by 
>> default, and consistency is sometimes better than special case rules, 
>> even if those special case rules make some things easier.
> 
> Nonsense, of course it's not too late! In fact, for this change in 
> particular, it's quite easy to write a trivial script that can easily 
> convert from one syntax to the other, without errors. So if you want to 
> argue about this proposal, do so regarding it's merits only, not 
> compatibility.
> 
> So about the consistency issue: I too think consistency and 
> orthogonality are very important (maybe even more than you :P ), but the 
> key thing to notice here is that a (private) import is not defining new 
> members of a module. It's not creating a new entity or entities. I view 
> an import as very different from defining a class, struct, variable, 
> function, etc., and therefore I don't find it inconsistent for the 
> default protection to be different.
> 
> In fact, I even have some doubts about the whole thing of imports having 
> protection attributes in the first place. It wouldn't strike me as odd 
> if import was protectionless, working only the same as the current 
> "private import", and that the functionality of the current "public 
> import" were achieved in some other way like "alias somemodule.*;" or 
> "aliasimport somemodule;" or something like that.
> 
> => One clue that an import is different from any other declarations with 
> protection attributes, is that its names go to a secondary namespace. 
> That's inconsistency right there. (if you view the imports the same as 
> the other things)
> 

Well said - you beat me to it <g> Especially the last point, which is a 
great argument against strict consistency and orthogonality for imports 
because as declarations some of their properties stand alone.