import concerns (was Re: Historical language survey)

[Derek Parnell]

On Sat, 08 Jul 2006 18:07:34 +1000, Ivan Senji  
<ivan.senji_REMOVE_ at _THIS__gmail.com> wrote:

> Derek Parnell wrote:
>> On Sat, 08 Jul 2006 14:47:34 +1000, Walter Bright
>> <newshound at digitalmars.com> wrote:
>>
>>> Brad Roberts wrote:
>>
>>>>  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.
>>
>> No.... what would happen if something outside the module called
>> foo(long) is that foo(int) would be called due to implicit casts and
>> that the module's foo(long) is invisible to the caller. It wouldn't be
>> called because the caller should not be able to see it.
>>
>
> Yes, but:
> If the functions were actually:
>
> void foo(int x);
> private void foo(char[] x);
>
> and in another module foo("bar"); the right function would be called
> even though it is private.
> The problem: the caller does see it if there is another function with
> the same name.

I agree that that is the problem. Calling foo("bar") should fail as that  
is private to the module and the caller should not be able to access it  
*BECAUSE* it is private even though the compiler can actually 'see' it.

-- 
Derek Parnell
Melbourne, Australia