[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #14 from d...@dawgfoto.de 2012-09-06 04:21:38 PDT --- Besides C++ people seem to draw the same conclusions. http://www.youtube.com/watch?v=8SOCYQ033K8t=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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #8 from d...@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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #9 from timon.g...@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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #10 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-05 18:16:11 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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #11 from timon.g...@gmx.ch 2012-09-05 18:49:03 PDT --- (In reply to comment #10) 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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #12 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-05 19:26:03 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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #6 from Walter Bright bugzi...@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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #7 from Jonathan M Davis jmdavisp...@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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #3 from Jonathan M Davis jmdavisp...@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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #4 from Andrej Mitrovic andrej.mitrov...@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: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #1 from Peter Alexander peter.alexander...@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: ---
