www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3113] New: final overriding

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113

           Summary: final overriding
           Product: D
           Version: 2.030
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: tim.matthews7 gmail.com


This code compiles:

module test;

enum A
{
    a = 0 
}

enum B
{
    b = 1
}

class BaseClass
{
    final A getEnum()
    {
        return A.a;
    }
}

class DerivedClass : BaseClass
{
    B getEnum()
    {
        return B.b;
    }
}



void main()
{
    auto der = new DerivedClass();
    der.getEnum();
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |yebblies gmail.com
         Resolution|                            |INVALID



B getEnum()
is not overriding
final A getEnum()

It's simply creating a new function.

Yet another reason the override attribute should be compulsory.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113


klickverbot <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |code klickverbot.at
         Resolution|INVALID                     |



---
Reopening this, as the compiler doesn't even error out with the »-w« switch
–
the »override compulsory« check seems to be broken in the presence of
»final«.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113






 Reopening this, as the compiler doesn't even error out with the »-w« switch
–
 the »override compulsory« check seems to be broken in the presence of
»final«.


Where should the override attribute be required?  There is no overriding
happening anywhere in the example.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113




---




 Reopening this, as the compiler doesn't even error out with the »-w« switch
–
 the »override compulsory« check seems to be broken in the presence of
»final«.


 
 Where should the override attribute be required?  There is no overriding
 happening anywhere in the example.


Remove the »final« attribute and compile the example with -w, and you'll see.

Besides, since when would it be allowed to have two public methods with the
same signature?


---




 Reopening this, as the compiler doesn't even error out with the »-w« switch
–
 the »override compulsory« check seems to be broken in the presence of
»final«.


 
 Where should the override attribute be required?  There is no overriding
 happening anywhere in the example.


Remove the »final« attribute and compile the example with -w, and you'll see.

Besides, since when would it be allowed to have two public methods with the
same signature?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113




---




 Reopening this, as the compiler doesn't even error out with the »-w« switch
–
 the »override compulsory« check seems to be broken in the presence of
»final«.


 
 Where should the override attribute be required?  There is no overriding
 happening anywhere in the example.


Remove the »final« attribute and compile the example with -w, and you'll see.

Besides, since when would it be allowed to have two public methods with the
same signature?


---




 Reopening this, as the compiler doesn't even error out with the »-w« switch
–
 the »override compulsory« check seems to be broken in the presence of
»final«.


 
 Where should the override attribute be required?  There is no overriding
 happening anywhere in the example.


Remove the »final« attribute and compile the example with -w, and you'll see.

Besides, since when would it be allowed to have two public methods with the
same signature?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



Even if D is working according to specs, I think this is bug-prone enough to
deserve some warning or even an error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113






 
 Remove the »final« attribute and compile the example with -w, and you'll see.
 


I get an error when compiling without the final attribute, -w or not.

testx.d(21): Error: function testx.DerivedClass.getEnum of type B() overrides
but is not covariant with testx.BaseClass.getEnum of type A()


 Besides, since when would it be allowed to have two public methods with the
 same signature?


Yes, overloading on return type is disabled for functions in the same scope,
but the rules are a little less strict for deriving classes...
Looking at the spec, it seems to be explicitly disallowed for functions that
would otherwise be virtual.
It can be very useful with template functions, as they need to be redefined in
each class, and is allowed for static functions.

I might be misunderstanding, please post a test case that shows what you mean.



 Even if D is working according to specs, I think this is bug-prone enough to
 deserve some warning or even an error.


I think it would be much clearer if override was mandatory, and I'm fairly sure
there's already a report for that.  If there's something else you'd like,
please, write it up.  A test case that compiles does not constitute an
enhancement request without additional information. (unless it's very, very
obvious)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com



07:54:25 PDT ---
I think it is a bug.  If the case was that a final function could be masked by
a derived class, then this should compile:

module test;

enum A
{
    a = 0,
    b = 1
}

class BaseClass
{
    final A getEnum()
    {
        return A.a;
    }
}

class DerivedClass : BaseClass
{
    A getEnum()
    {
        return A.b;
    }
}

But I get the error:
bug3113.d(19): Error: function test.DerivedClass.getEnum cannot override final
function test.BaseClass.getEnum

This occurs even when I mark DerivedClass' function as final.

I was about to mark this as invalid, citing this as a better example, but since
the compiler complains about masking in this case, I don't see why the original
case is allowed.  I believe this kind of thing is allowed in C++.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113




---


 This occurs even when I mark DerivedClass' function as final.


I think it is quite clear that the example you gave shouldn't compile, as the
spec has: »Functions marked as final may not be overridden in a derived class,
unless they are also private.«

The question now is whether the same behavior should also apply to the example
from above. I'm strongly in favor of that, because otherwise, there can be
situation where the following two pieces of code don't refer to the same
»bar()«, which is completely contrary to how classes usually work in D:

---
auto foo = new Derived();
foo.bar();
---

---
Base foo = new Derived();
foo.bar();
---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113








 This occurs even when I mark DerivedClass' function as final.


 
 I think it is quite clear that the example you gave shouldn't compile, as the
 spec has: »Functions marked as final may not be overridden in a derived class,
 unless they are also private.«
 
 The question now is whether the same behavior should also apply to the example
 from above. I'm strongly in favor of that, because otherwise, there can be
 situation where the following two pieces of code don't refer to the same
 »bar()«, which is completely contrary to how classes usually work in D:
 


Would you also apply this rule to static and template functions?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3113




08:20:45 PDT ---





 This occurs even when I mark DerivedClass' function as final.


 
 I think it is quite clear that the example you gave shouldn't compile, as the
 spec has: »Functions marked as final may not be overridden in a derived class,
 unless they are also private.«
 
 The question now is whether the same behavior should also apply to the example
 from above.




I don't think this is really overriding.  You can still call the base function.
 It's more like masking.  But the compiler is definitely behaving
inconsistently, so it's still a bug, either way.


 I'm strongly in favor of that, because otherwise, there can be
 situation where the following two pieces of code don't refer to the same
 »bar()«, which is completely contrary to how classes usually work in D:
 


 Would you also apply this rule to static and template functions?


I would actually recommend to nix that part of the language, just allow masking
of final functions as long as they are not marked override.  I.e. final stops
the virtual chain, and any derived class will not be able to override the base
virtual function.  However, it can start up a new chain by *not* specifying
override.  I think that requiring override is essential to doing something like
this.

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