From his comments in the std.compress thread, Walter seems to believe that private symbols are not visible. This is not the case, and has never been the case. In current DMD, private symbols will name conflict with public symbols from other modules.

This has been discussed several times, and Dicebot has put together a proposal in DIP22.

http://wiki.dlang.org/DIP22

I want to open this up again because the previous thread died off with no conclusion. I urge Walter/Andrei to approve this if they are happy with it so that the compiler devs have the greenlight to put the fix in. It has been a longstanding issue with the language, and your approval is the only thing blocking it from finally being resolved.

On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
> http://wiki.dlang.org/DIP22

"I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea"

How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?

On Tue, 04 Jun 2013 14:10:32 -0400, Max Samukha <maxsamukha@gmail.com> wrote:

> On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
>> http://wiki.dlang.org/DIP22
>
> "I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea"
>
> How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?

Looking at the original comment here: http://forum.dlang.org/post/kb86il$1u9v$1@digitalmars.com

It looks like Jonathan raised the same point, but Walter never answered.

Since protected access is actually ESSENTIAL in OOP (at least, some form of virtual non-public function access, private is not virtual, so it would be disastrous to remove protected), I am wondering whether Walter really meant "package", as that has very little utility.

Care to answer, Walter?

-Steve

On Tuesday, 4 June 2013 at 18:33:21 UTC, Steven Schveighoffer wrote:
> Since protected access is actually ESSENTIAL in OOP (at least, some form of virtual non-public function access, private is not virtual, so it would be disastrous to remove protected), I am wondering whether Walter really meant "package", as that has very little utility.

"package" may become quite useful once we have better package. It allows to have some local "utility" module used by specific package but not generic enough in global so that it won't cause name collision (after DIP22 is implemented, of course).

On Tue, 04 Jun 2013 15:13:30 -0400, Dicebot <m.strashun@gmail.com> wrote:

> On Tuesday, 4 June 2013 at 18:33:21 UTC, Steven Schveighoffer wrote:
>> Since protected access is actually ESSENTIAL in OOP (at least, some form of virtual non-public function access, private is not virtual, so it would be disastrous to remove protected), I am wondering whether Walter really meant "package", as that has very little utility.
>
> "package" may become quite useful once we have better package. It allows to have some local "utility" module used by specific package but not generic enough in global so that it won't cause name collision (after DIP22 is implemented, of course).

Sure, but I'm trying to read the comment in the context it was in.  Certainly, if Daniel's patch to allow package imports is accepted, then package becomes almost essential for splitting up a module :)

But at the time this comment was made, none of that was on the table.  And removing protected would be disastrous.  I can't fathom why he said protected should be removed.  Which is why I hypothesized that he really meant package.  But I'd rather just let Walter explain what he meant at this point...

-Steve

On 06/04/2013 08:10 PM, Max Samukha wrote:
> On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
>> http://wiki.dlang.org/DIP22
>
> "I'd also throw in getting rid of the "protected" access attribute
> completely, as I've seen debate over that being a useless idea"
>
> How is that useless? Any non-trivial OOP code
> (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions)
> swarm with protected methods, and rightfully so. How would one restrict
> access to members that are not part of public interface but should be
> accessible to the derived classes?

I don't think it is possible. protected methods are part of the public interface, since inheritance cannot be restricted selectively.

Am Tue, 04 Jun 2013 20:10:32 +0200
schrieb "Max Samukha" <maxsamukha@gmail.com>:

> On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
> > http://wiki.dlang.org/DIP22
> 
> "I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea"
> 
> How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?

On a different note, it could be disallowed on structs if it is allowed there, to avoid confusion about its effect there.

-- 
Marco

On Tuesday, 4 June 2013 at 18:33:21 UTC, Steven Schveighoffer wrote:

>
> Since protected access is actually ESSENTIAL in OOP (at least, some form of virtual non-public function access, private is not virtual, so it would be disastrous to remove protected), I am wondering whether Walter really meant "package", as that has very little utility.
>
> Care to answer, Walter?
>
> -Steve

'package' cannot possibly solve the problem because the protected members should be accessible outside of the defining package.

On Tuesday, 4 June 2013 at 21:32:32 UTC, Timon Gehr wrote:
> On 06/04/2013 08:10 PM, Max Samukha wrote:
>> On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
>>> http://wiki.dlang.org/DIP22
>>
>> "I'd also throw in getting rid of the "protected" access attribute
>> completely, as I've seen debate over that being a useless idea"
>>
>> How is that useless? Any non-trivial OOP code
>> (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions)
>> swarm with protected methods, and rightfully so. How would one restrict
>> access to members that are not part of public interface but should be
>> accessible to the derived classes?
>
> I don't think it is possible. protected methods are part of the public interface, since inheritance cannot be restricted selectively.

I don't quite understand. Could you explain?