June 16, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3113



--- Comment #10 from yebblies <yebblies@gmail.com> 2011-06-16 08:09:46 PDT ---
(In reply to comment #9)
> (In reply to comment #8)
> > 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: -------
June 16, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3113



--- Comment #11 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-06-16 08:20:45 PDT ---
> (In reply to comment #9)
> > (In reply to comment #8)
> > > 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: -------
1 2
Next ›   Last »