import concerns (was Re: Historical language survey)

[Sean Kelly]

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'm not sure this is an entirely valid example because private member 
functions in D are not inherited and therefore should never be 
considered for overload resolution in a derived class.  Assuming the new 
"truly invisible" private behavior, I would expect the lookup mechanism 
to first search the local class scope, then public/protected inherited 
scopes, then module scope, then imported module scopes.  Once a match is 
found, the overload mechanism should evaluate only the other visible 
functions at the scope of the match.  I'll admit that this sounds like 
it would require re-engineering the overload resolution code a bit, but 
I think the result would probably be more clear to the inexperienced user.


Sean