http://d.puremagic.com/issues/show_bug.cgi?id=5420

           Summary: Cannot override function error
           Product: D
           Version: D2
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: eatingstaples@gmail.com


--- Comment #0 from eatingstaples@gmail.com 2011-01-06 18:35:48 PST ---
Derived classes cannot override functions in base classes, if the base class is private or package, even if the derived class carries the same attribute.

The compiler issues an error explaining that the function in the derived class does not, in fact, override a function in the base class.

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

http://d.puremagic.com/issues/show_bug.cgi?id=5420



--- Comment #1 from eatingstaples@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5420


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

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


--- Comment #2 from Jonathan M Davis <jmdavisProg@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5420



--- Comment #3 from eatingstaples@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5420



--- Comment #4 from eatingstaples@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5420



--- Comment #5 from eatingstaples@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5420


eatingstaples@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    Attachment #863|Code attached with the      |Code attached with the
        description|problem fixed               |problem fixed.


--- Comment #6 from eatingstaples@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5420



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-01-06 20:03:47 PST ---
Hmmmm. 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5420


Christopher Nicholson-Sauls <ibisbasenji@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibisbasenji@gmail.com


--- Comment #8 from Christopher Nicholson-Sauls <ibisbasenji@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5420


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |WORKSFORME


--- Comment #9 from Walter Bright <bugzilla@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: -------