[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WORKSFORME --- Comment #9 from Walter Bright bugzi...@digitalmars.com 2012-01-20 16:20:51 PST --- The original example compiles without error on 2.057. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 --- Comment #1 from eatingstap...@gmail.com 2011-01-06 18:36:58 PST --- Created an attachment (id=862) Code demonstrating various working and non-working overrides -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2011-01-06 18:55:12 PST --- As it stands, I don't believe that this is actually an error. All private functions are non-virtual, and package functions probably are as well. protected and and public functions _are_ virtual and so can be overridden. It _is_ true that in C++ you can override private functions, but there is some debate as to whether you should be allowed to in D. TDPL claims that you can, which would imply that dmd will have to be changed to make it possible to make private and package functions virtual (which could actually harm efficiency a fair bit due to the inability to inline), but there have been definite arguments against it, since you can essentially use protected in any case where you'd use private. See bug# 4542. This is one of those cases where it's not clear whether dmd is going to end up matching TDPL or whether TDPL will have to be changed in future editions. I don't believe that Walter has said anything about what he intends to do on the matter. There have been discussions about this on the newsgroup before. Personally, I'm rather divided. NVI is definitely useful, but you can pretty much do it with protected, and it's not clear that private actually buys you much over using protected. And given that making private virtual would seriously harm inlining, that would tend to indicate that perhaps TDPL should be changed rather than dmd. I don't know though, and until Walter decides and tells us what he decided, we won't know. You might wan to go search the archives for discussions on the issue though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 --- Comment #3 from eatingstap...@gmail.com 2011-01-06 19:37:13 PST --- I understand that, but I didn't realize it applied even to public functions in private classes. That seems nonsensical, as there may be entire hierarchies hidden inside a package which can then not use any virtual functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 --- Comment #4 from eatingstap...@gmail.com 2011-01-06 19:50:40 PST --- Looking over the D2 language documentation, I still see no reason that this should be occurring; All non-static non-private non-template member functions are virtual. and Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class. Private members cannot be overridden. Private module members are equivalent to static declarations in C programs. Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages. Nowhere can I find that it says declaring a class private or package causes its members to be considered the same. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 eatingstap...@gmail.com changed: What|Removed |Added Attachment #863|Code attached with the |Code attached with the description|problem fixed |problem fixed. --- Comment #6 from eatingstap...@gmail.com 2011-01-06 19:52:46 PST --- (From update of attachment 863) Explicitly declaring the members public fixes the problem. However, members are public by default, so this appears to be a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 --- Comment #5 from eatingstap...@gmail.com 2011-01-06 19:51:37 PST --- Created an attachment (id=863) Code attached with the problem fixed -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 --- Comment #7 from Jonathan M Davis jmdavisp...@gmx.com 2011-01-06 20:03:47 PST --- H. Well, I believe that members are public by default because public is the default access level of the class. If you mark the class as private, that would mark _all_ of its functions as private, just like marking a class as immutable makes all of its functions immutable. So, that's not a bug. A bit annoying perhaps, but not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5420] Cannot override function error
http://d.puremagic.com/issues/show_bug.cgi?id=5420 Christopher Nicholson-Sauls ibisbase...@gmail.com changed: What|Removed |Added CC||ibisbase...@gmail.com --- Comment #8 from Christopher Nicholson-Sauls ibisbase...@gmail.com 2011-01-06 21:15:51 PST --- Like Jon said, this is consistent with how other decorations on classes are treated: they propagate to members. Declare a class as const, immutable, or even shared (!?), and all members are treated likewise. If nothing else, you can always get in the habit of adding 'public:' at the beginning of such classes. (Plenty of people do that already, out of C++ habit.) I'm definitely not saying it isn't going to be annoying, but I think it fits the language (as is). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
