import concerns (was Re: Historical language survey)

[Brad Roberts]

Walter Bright wrote:
> Brad Roberts wrote:
>> Walter Bright wrote:
>>> Derek Parnell wrote:
>>>> On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright 
>>>> <newshound at digitalmars.com> wrote:
>>>>
>>>>> The alias works at any level you choose to make it. Alias can be 
>>>>> used to 'import' any name into the current namespace, making it 
>>>>> first class.
>>>>
>>>> Even names that are declared 'private' in the imported module? Is 
>>>> that how you want it to work Walter? If so, why do we bother with 
>>>> 'private'? What's the point?
>>>
>>> In class scope, access control is done *after* name lookup, not 
>>> before. I'm concerned about confusion by reversing the order of that 
>>> for module scope.
>>
>> How much begging would it take to try for a release or two having 
>> private symbols invisible to the importer?  It's really much more 
>> intuitive, imho.  I haven't looked at this part of the front end code, 
>> but if it's easy, feel free to make it controllable via a compiler 
>> option just for the experiment's time frame.
> 
> The problems happen when one has:
> 
> void foo(int x);
> private void foo(long x);
> 
> So the first foo is found, then overload rules apply, and the second foo 
> is selected.

Um.. finding the second foo means that it's not invisible.  It should 
not exist as far as anything outside the module is concerned.  It's 
private, internal, period.  About the only part of existence that a 
private symbol has is in determining the size of a struct or class.  But 
beyond occupying space, it shouldn't have any interaction at all.  They 
just shouldn't exist in the symbol table at all.

Is there something about private symbols existing that all the rest of 
us are over looking that makes it important for them to be visible?

Later,
Brad