import concerns (was Re: Historical language survey)

[kris]

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

FWIW, you've got my support to make private actually mean Private (with 
a capital P). Anything else is surely counter-intuitive; certainly seems 
to ignore any "principal of least surprise"