I made a pull request to fix private/package access checks.
https://github.com/D-Programming-Language/dmd/pull/669

Now I'm wondering if that goes into the right direction.

The shallow distinction of visibility vs. accessibility breaks the module system because
one can't safely add a private symbol without possibly affecting every dependent module.
Thus we're back at using underscore names to protect from that.

From implementing access checks I found the right amount of checking is to do them
when resolving identifiers. Thus it's almost equal to visibility based protection.

We already hide symbols that are privately imported by an imported module.

martin

On 2/12/12 7:28 PM, Martin Nowak wrote:
> The shallow distinction of visibility vs. accessibility breaks the
> module system because
> one can't safely add a private symbol without possibly affecting every
> dependent module.
> Thus we're back at using underscore names to protect from that.

Yes, and this is exactly why I argued to disregard invisible symbols during overload resolution in the past. Walter seems to be firmly convinced that the current solution is the right thing to do, but I can't recall what his reasons were.

David

On Sun, 12 Feb 2012 19:32:28 +0100, David Nadlinger <see@klickverbot.at> wrote:

> On 2/12/12 7:28 PM, Martin Nowak wrote:
>> The shallow distinction of visibility vs. accessibility breaks the
>> module system because
>> one can't safely add a private symbol without possibly affecting every
>> dependent module.
>> Thus we're back at using underscore names to protect from that.
>
> Yes, and this is exactly why I argued to disregard invisible symbols during overload resolution in the past. Walter seems to be firmly convinced that the current solution is the right thing to do, but I can't recall what his reasons were.
>
> David

Overloading is only the trickier part of it, but it affects all other symbols as well.
As far as overloading goes C++ does it one way and Java choses the other.
IMHO mixing protection levels for overloads could be disallowed.

Agreed with David. I find these things a pointless waste of time:

module a;
private {
    struct foo {
    }
}

module b;
void foo() { }

import a;
import b;

void main() {
    foo();
}

main.d(7): Error: a.foo at a.d(3) conflicts with b.foo at b.d(2)
main.d(7): Error: structliteral has no effect in expression (foo())

One of those cases exists in Phobos somewhere, where a private type is declared with the same name as an unrelated public function in some other module. I can't recall which module it is though.

On Sunday, February 12, 2012 19:32:28 David Nadlinger wrote:
> On 2/12/12 7:28 PM, Martin Nowak wrote:
> > The shallow distinction of visibility vs. accessibility breaks the
> > module system because
> > one can't safely add a private symbol without possibly affecting every
> > dependent module.
> > Thus we're back at using underscore names to protect from that.
> 
> Yes, and this is exactly why I argued to disregard invisible symbols during overload resolution in the past. Walter seems to be firmly convinced that the current solution is the right thing to do, but I can't recall what his reasons were.

I'm not 100% sure that it's a good idea, depending on what the exact side effects are, but in principle, I'd love it if private symbols were invisible to other modules.

Now, this does _not_ fly with private being overridable, as TDPL claims it should be. But I've already argued that that was a mistake due to the performance issues that it causes. I'm not sure what Walter's current plans with that are though.

http://d.puremagic.com/issues/show_bug.cgi?id=4542

- Jonathan M Davis

On Mon, 13 Feb 2012 19:07:20 +0100, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, February 12, 2012 19:32:28 David Nadlinger wrote:
>> On 2/12/12 7:28 PM, Martin Nowak wrote:
>> > The shallow distinction of visibility vs. accessibility breaks the
>> > module system because
>> > one can't safely add a private symbol without possibly affecting every
>> > dependent module.
>> > Thus we're back at using underscore names to protect from that.
>>
>> Yes, and this is exactly why I argued to disregard invisible symbols
>> during overload resolution in the past. Walter seems to be firmly
>> convinced that the current solution is the right thing to do, but I
>> can't recall what his reasons were.
>
> I'm not 100% sure that it's a good idea, depending on what the exact side
> effects are, but in principle, I'd love it if private symbols were invisible to
> other modules.
>
> Now, this does _not_ fly with private being overridable, as TDPL claims it
> should be. But I've already argued that that was a mistake due to the
> performance issues that it causes. I'm not sure what Walter's current plans
> with that are though.
>
Can you elaborate on what issues you see with NVI. After all it's only the final public
method that needs to call the virtual private methods.

On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
> Can you elaborate on what issues you see with NVI. After all it's only the
> final public
> method that needs to call the virtual private methods.

As I explain in that bug report, NVI can be acheived with protected rather than private. So, we can do NVI now with private being non-virtual. However, if we make private virtual, then the compiler can no longer inline private functions in classes unless they're marked as final. That's a performance hit to pretty much every class ever written.

Yes, the conscientious programmer will mark their classes' private functions final unless they intend to use them for NVI, but the _default_ is then inefficient for little to no gain. All you gain is the ability to do NVI with private instead of protected, and that is not even vaguely worth the performance hit to almost every D class ever IMHO.

- Jonathan M Davis

On 02/14/2012 12:26 AM, Jonathan M Davis wrote:
> On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
>> Can you elaborate on what issues you see with NVI. After all it's only the
>> final public
>> method that needs to call the virtual private methods.
>
> As I explain in that bug report, NVI can be acheived with protected rather
> than private. So, we can do NVI now with private being non-virtual. However,
> if we make private virtual, then the compiler can no longer inline private
> functions in classes unless they're marked as final. That's a performance hit
> to pretty much every class ever written.
>
> Yes, the conscientious programmer will mark their classes' private functions
> final unless they intend to use them for NVI, but the _default_ is then
> inefficient for little to no gain. All you gain is the ability to do NVI with
> private instead of protected, and that is not even vaguely worth the
> performance hit to almost every D class ever IMHO.
>
> - Jonathan M Davis

Virtual private does not allow for cross-module NVI, so what would be the point anyway?

On Tuesday, February 14, 2012 00:36:31 Timon Gehr wrote:
> On 02/14/2012 12:26 AM, Jonathan M Davis wrote:
> > On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
> >> Can you elaborate on what issues you see with NVI. After all it's only
> >> the final public
> >> method that needs to call the virtual private methods.
> > 
> > As I explain in that bug report, NVI can be acheived with protected rather than private. So, we can do NVI now with private being non-virtual. However, if we make private virtual, then the compiler can no longer inline private functions in classes unless they're marked as final. That's a performance hit to pretty much every class ever written.
> > 
> > Yes, the conscientious programmer will mark their classes' private functions final unless they intend to use them for NVI, but the _default_ is then inefficient for little to no gain. All you gain is the ability to do NVI with private instead of protected, and that is not even vaguely worth the performance hit to almost every D class ever IMHO.
> > 
> > - Jonathan M Davis
> 
> Virtual private does not allow for cross-module NVI, so what would be the point anyway?

Why wouldn't it? The whole point of NVI is that you override it but don't call it - the base class does that. So, the derived class could override the private function but couldn't call it. It _is_ a bit weird though, all the same.

Regardless, I'm against making private virtual because of the needless performance hit.

- Jonathan M Davis

On Tue, 14 Feb 2012 00:26:14 +0100, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
>> Can you elaborate on what issues you see with NVI. After all it's only the
>> final public
>> method that needs to call the virtual private methods.
>
> As I explain in that bug report, NVI can be acheived with protected rather
> than private. So, we can do NVI now with private being non-virtual. However,
> if we make private virtual, then the compiler can no longer inline private
> functions in classes unless they're marked as final. That's a performance hit
> to pretty much every class ever written.
>
> Yes, the conscientious programmer will mark their classes' private functions
> final unless they intend to use them for NVI, but the _default_ is then
> inefficient for little to no gain. All you gain is the ability to do NVI with
> private instead of protected, and that is not even vaguely worth the
> performance hit to almost every D class ever IMHO.
>
> - Jonathan M Davis

OK, that was known and I agree with you. I even find the concept of overriding private
functions flawed. I thought you had something in mind with overload resolution.