import concerns (was Re: Historical language survey)

[Derek Parnell]

On Sat, 08 Jul 2006 18:26:46 +1000, Walter Bright  
<newshound at digitalmars.com> 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  
>  lookup and after overload resolution.


I'm sorry Walter but I don't give newt's fart about C++. If I wanted to  
code under the rules of C++, I'd use C++. You have changed (improved) many  
of the C++ rules in D, so why not get this one right too?

Given the example above, I'd prefer that the overload resolution rules  
would not even consider S.foo(int) because its private (from the caller's  
perspective) so it would only see the public function and resolve  
overloads based on what it is allowed to access. Thus

  s.foo(1)

should call s.foo(long) because that is the only one accessible by the  
caller anyway.

Okay, so its not C++, so what! If anyone, including existing C++ coders,  
want to code in D they should learn D.

-- 
Derek Parnell
Melbourne, Australia