www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6180] New: Private has no effect on types in modules

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180

           Summary: Private has no effect on types in modules
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com



17:36:05 PDT ---
Example:

foo.d:
module foo;

private
{
    int x;
    class Foo {}
}

main.d:
module main;

import foo;

void main() 
{
    // x = 5; // Error: module main foo.x is private
    auto foo = new Foo();  // accepted!!
}

Currently I have a problem with clashing symbols between
std.concurrency.MessageBox which is a private class and the Windows bindings
win32.winuser.MessageBox, which is a public function. It's a very commonly used
function btw. My workaround is this after the last import:

alias win32.winuser.MessageBox MessageBox;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 19 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180


Peter Alexander <peter.alexander.au gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.alexander.au gmail.co
                   |                            |m



08:05:56 PDT ---
I'm working on fixing the fact that protection is ignored on user-defined
types, but until someone says otherwise, I won't be changing the overload
resolution rules to account for protection. Unless I've missed it, no where in
TDPL or on the website does it say that private symbols are invisible from
other modules, it only says that they cannot be accessed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 21 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180




09:46:08 PDT ---
I don't really understand this notion of "visibility" vs "accessibility".

Can someone show me some code that shows the difference between the two?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



PDT ---
In general, if a function is visible, then the compiler knows about it. If it
weren't visible, then the compiler wouldn't really see it when a module
imported the module that it's in. If it's visible but inaccessible, then the
compiler can see it, but it won't allow you to use it. So, for instance, if you
tried to use a private function, then it could complain about the function
being private, so you can't use it. But if it were not visible, then the
compiler would have to complain that you were trying to use a symbol that it
didn't know about.

Private symbols are perfectly visibile. They're just not accessible. All that
public, package, protected, and private affect is accessibility, not
visibility. They're _access_ modifiers. And overload resolution occurs _before_
accessibility is checked, which is part of the reason that you've been running
into issues with private stuff conflicting with public stuff.

You can check out this explanation with regards to C++ (which is essentially
the same):
http://meditation-art.blogspot.com/2007/11/c-function-visibility-and-accessibility.html

Also, look into NVI (Non-Virtual Inheritance). Herb Sutter discusses it in C++
here: http://www.gotw.ca/publications/mill18.htm

Assuming that private functions are overridable (which according to TDPL, they
should be, but they aren't currently in D), then derived classes can override
private functions without being able to call them. Andrei discusses it starting
at page 213 of TDPL. That wouldn't be possible if private functions weren't
visible.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180




10:13:15 PDT ---
Thanks Jon, that sheds the light on the issue. I guess this will be difficult
to solve then.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180


Christian Kamm <kamm-removethis incasoftware.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kamm-removethis incasoftwar
                   |                            |e.de
         Resolution|                            |DUPLICATE



23:22:20 PDT ---
*** This issue has been marked as a duplicate of issue 1441 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 20 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



19:54:26 PDT ---
Jonathan's summary is correct.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 04 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180




PDT ---
However, it _would_ be really nice if we could at least make it so that private
functions weren't considered in overload resolution. As it stands, things like
private aliases are completely useless because they essentially pollute the
global namespace (in the sense that they can cause overload conflicts, forcing
you to use the full path for the function, even though the private one is
inaccessible).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 04 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180


dawg dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg dawgfoto.de




And overload resolution occurs _before_ accessibility is checked


Not until we fix Bug 3254. The same bug thing now applies to the template
access checks.


Private symbols are perfectly visibile. They're just not accessible.
...
You can check out this explanation with regards to C++ (which is essentially


the same)


However, it _would_ be really nice if we could at least make it so that private


functions weren't considered in overload resolution.

In C++ headers are common and allow to hide implementation symbols. D's current
workaround are handwritten di files (object, core.thread) but we need a better
solution that is scalable and doesn't add redundancy. So far I only came up
with
 HideModuleMembers which hides protected module level symbols but keeps access
checks and overloading for nested scopes.
https://github.com/D-Programming-Language/dmd/pull/739

Probably it's time to rediscuss this on the mailing list.
http://www.digitalmars.com/d/archives/digitalmars/D/visibility_vs._accessibility_of_protected_symbols_157598.html

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180


timon.gehr gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr gmx.ch





 Jonathan's summary is correct.


It shouldn't be. The summary obviously describes horribly broken behaviour.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180




PDT ---

 It shouldn't be. The summary obviously describes horribly broken behaviour.


It describes how it works in C++ which is exactly how it works in D. It's that
way by design, and anything else would require that the language be changed.

What many have argued for is that private symbols should be hidden (or at least
not be considered in overload resolution when not accessible or otherwise cause
conflicts with accessible symbols), which I think would be a major improvement,
but that's not the way that it currently works or is ever expected to work
unless you can convince Walter to change it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180






 It shouldn't be. The summary obviously describes horribly broken behaviour.


 
 It describes how it works in C++


Irrelevant.


 which is exactly how it works in D. It's that way by design,


This does not matter either. It is an incorrect design.


 and anything else would require that the language be changed.
 
 What many have argued for is that private symbols should be hidden (or at least
 not be considered in overload resolution when not accessible or otherwise cause
 conflicts with accessible symbols), which I think would be a major improvement,


These are not conflicts. The compiler is deliberately lying about this.


 but that's not the way that it currently works or is ever expected to work
 unless you can convince Walter to change it.


Introducing a private module scope symbol currently is a breaking interface
change (even in code that does not use any metaprogramming!) This is
ridiculous.

I assume that Walter will figure it out.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180




PDT ---
D takes it access modifier design from C++, and it's purely a question of
accessibility, not visibility, even if many people expect it to affect
visibility. AFAIK, Walter doesn't think that there's anything wrong with it. I
have no idea how easy it will be to convince him otherwise. But if you don't
like the current design, then start a discussion in the newsgroup on it and
convince Walter.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180





D takes it access modifier design from C++, and it's purely a question of


accessibility, not visibility, even if many people expect it to affect
visibility.

C++ doesn't have access modifiers on global scope, only within classes/structs.
It's primarily needed to restrict access while making all fields visible for
the memory layout.
The C++ way of hiding symbols is to not expose them in headers and using
anonymous namespaces for sources.
Using access modifiers for types and functions in D's source only modules has
no equivalence in C++. And because unqualified imports are the default we're
getting namespaces clashes as with header includes. The hijack protection is
only a safety net but it doesn't protect against breaking software.

Reading the first paragraph of http://dlang.org/hijack.html it becomes clear
that we missed an important design goal.


The mod­ule developers must be able to maintain and improve those modules
without inadvertently stepping on the behavior of modules over which they
cannot have knowledge of.


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 06 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6180




Besides C++ people seem to draw the same conclusions.
http://www.youtube.com/watch?v=8SOCYQ033K8&t=4m41s
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2006.pdf

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 06 2012