import concerns (was Re: Historical language survey)

[Lars Ivar Igesund]

Derek Parnell wrote:

> 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.
> 

I agree, private means private.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi