June 20, 2011
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


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-06-19 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: -------
June 21, 2011
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


--- Comment #1 from Peter Alexander <peter.alexander.au@gmail.com> 2011-06-21 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: -------
June 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6180



--- Comment #2 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-06-25 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: -------
June 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6180


Jonathan M Davis <jmdavisProg@gmx.com> changed:

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


--- Comment #3 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-06-25 10:06:39 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: -------
June 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6180



--- Comment #4 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-06-25 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: -------
August 21, 2011
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


--- Comment #5 from Christian Kamm <kamm-removethis@incasoftware.de> 2011-08-20 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: -------
September 05, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6180


Walter Bright <bugzilla@digitalmars.com> changed:

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


--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> 2012-09-04 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: -------
September 05, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6180



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-09-04 20:00:57 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: -------
September 05, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6180


dawg@dawgfoto.de changed:

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


--- Comment #8 from dawg@dawgfoto.de 2012-09-05 06:03:29 PDT ---
>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: -------
September 06, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6180


timon.gehr@gmx.ch changed:

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


--- Comment #9 from timon.gehr@gmx.ch 2012-09-05 17:59:31 PDT ---
(In reply to comment #6)
> 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: -------
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home