www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1918] New: __traits(getVirtualFunctions) returns final functions

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

           Summary: __traits(getVirtualFunctions) returns final functions
           Product: D
           Version: 2.012
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: dhasenan gmail.com


static assert(__traits(getVirtualFunctions, Object, "notifyRegister").length ==
0);

That should succeed; Object.notifyRegister is final and therefore not virtual.

Clearer example:
class C
{
   final void foo(){}
}
static assert(__traits(getVirtualFunctions, C, "foo").length == 0);

That also fails.


-- 
Mar 12 2008
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918






Okay, I've worked out how all this works.

__traits (getVirtualFunctions) gets all non-static methods.

__traits (isVirtualFunction) returns true iff the argument is a non-static
method.

__traits (isFinalFunction) returns true iff __traits (isVirtualFunction)
returns true and the function is not marked final.

This is consistent, and 'fixing' the issues by changing features would result
in a loss of functionality.

This is not consistent with the expected meaning of "virtual function". I
request that the documentation for __traits be updated to include a definition
for "virtual function".

I also request that the keywords be changed to "getInstanceMethods" and
"isInstanceMethod" or something like that, for clarity.


-- 
Nov 16 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918




Commit pushed to
https://github.com/D-Programming-Language/d-programming-language.org

https://github.com/D-Programming-Language/d-programming-language.org/commit/d096698029399aaf2e2f62527173d80e8ef24cb4
fix Issue 1918 - __traits(getVirtualFunctions) returns final functions

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918


Walter Bright <bugzilla digitalmars.com> changed:

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


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |andrei metalanguage.com
         Resolution|FIXED                       |



22:17:45 PST ---
Could you please explain how a final function that doesn't override anything is
ever supposed to be virtual?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement



22:58:29 PST ---
Documenting the agreement reached with Walter:

We'll define __traits(getVirtualMethods) to do the "right" thing, i.e. only
include final methods that actually override something, and put
__traits(getVirtualFunctions) on the slow deprecation path.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com




 Could you please explain how a final function that doesn't override anything is
 ever supposed to be virtual?
Final functions can be seen as the end of a chain of overridden functions - even if the functions is also the first in the chain and therefore never uses virtual dispatch. Either definition could be useful so having both available is probably the best solution. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



PST ---
Why would it be useful to have a non-virtual function listed as a virtual
function? Because that's what you're doing when mark a function which doesn't
override anything final. It's _not_ in any kind of override chain.

Imagine for a moment that private functions become virtual by default like TDPL
says (which I still hopes doesn't happen, since it'll be a major blow to the
efficiency of the language) and final functions which didn't override anything
were listed as virtual functions, pretty much _every_ function would then be
returned by getVirtualFunctions.

If you're using getVirtualFunctions or getVirtualMethods or whatever, then you
want the _virtual_ functions. As such, I see _zero_ reason to be returning
final functions which don't override anything, and so I see no reason to keep
getVirtualFunctions around.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918




Commit pushed to https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/adb62254d26ab0b29f543f2562a55b331f4ef297
fix Issue 1918 - __traits(getVirtualFunctions) returns final functions

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918




Commit pushed to
https://github.com/D-Programming-Language/d-programming-language.org

https://github.com/D-Programming-Language/d-programming-language.org/commit/89f321f5ee0d0c3eeed478a70ef1cd79116c6736
fix Issue 1918 - __traits(getVirtualFunctions) returns final functions

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918





 Why would it be useful to have a non-virtual function listed as a virtual
 function? Because that's what you're doing when mark a function which doesn't
 override anything final. It's _not_ in any kind of override chain.
Well, you make some good points. I'm not entirely convinced there isn't some template forwardingy application (are there any uses for __traits(getVirtualFunctions)?) that would find the other way useful. Anyway, I'm not sure this fix is correct. After a little bit of poking around I discovered that a final method that doesn't override anything IS STILL VIRTUAL. It still creates a vtable slot. Is this a bug? From what I can tell that means there is no way to actually create a non-virtual non-static member function. If final functions that do not override anything were implicitly non-virtual, it would fix this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918




PST ---
final functions which don't override anything _definitely_ shouldn't be
virtual. There's no reason for them to be virtual, and it harms performance. If
the compiler fails to make them non-virtual, then that's definitely a bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 23 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1918





 final functions which don't override anything _definitely_ shouldn't be
 virtual. There's no reason for them to be virtual, and it harms performance. If
 the compiler fails to make them non-virtual, then that's definitely a bug.
By the looks of it, the compiler manages to optimize out the virtual call with all final functions, which is probably why nobody ever noticed this before. The problem seems to be that whether the functions actually needs a vtable slot is resolved much too late. This is essential for linking with c++, which I'm trying to improve. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 23 2012