import concerns (was Re: Historical language survey)

[Ivan Senji]

Ivan Senji wrote:
> Walter Bright wrote:
>> Ivan Senji wrote:
>>> How does this sound in the documentation:
>>> "A module level function that is declared private can not be used in
>>> another module unless there is another public function with the same
>>> name."
>>> <- This is just crazy(or does it justsound crazy to me), IMO private
>>> "void foo(long x);" in the above example should not be included in the
>>> overload resolution.
>> Consider the following C++ code:
>>
>> struct S
>> {
>>     public void foo(long);
>>     private void foo(int);
>> };
>> struct T
>> {
>>     public void foo(long);
>> };
>>
>> ....
>>
>> S s;
>> s.foo(1);    // error, foo(int) is private
>> T t;
>> t.foo(1);    // ok
>>
>> Note that it sees S::foo(int) and it participates in overload resolution
>> even though it is private. In other words, accessibility is checked
>> after lookup and after overload resolution.
> 
> I really do understand the way C++ does things, but are you sure this is
> the best/smartest way? We all know that D is not C++(a Good Thing).
> I think that to most people private will mean that whatever is declared
> private is invisible (in another module).
> 
> More C++ code (methods a little bit more different to avoid thinking
> about implicit type conversions):
> 
> struct S
> {
>     public: void foo(int a){}
>     private: void foo(string b){}
> };
> 
> S s;
> s.foo(1);
> s.foo("Bla"); <- atleast in C++(unlike D) this isn't allowed, i got a
> message:

I should point out that I know that this is a bug in the current D
implementation, but it is a bug that would not be possible if the
compiler just didn't see/ignored private stuff from other modules.

By private stuff I also mean private classes.