www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5420] New: Cannot override function error

reply d-bugmail puremagic.com writes:
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



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: -------
Jan 06 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5420




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: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5420


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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


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: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5420




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: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5420




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: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5420




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: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5420


eatingstaples gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------

        description|problem fixed               |problem fixed.



(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: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5420




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: -------
Jan 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5420


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |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: -------
Jan 06 2011
prev sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jan 20 2012