digitalmars.D.bugs - [Issue 1918] New: __traits(getVirtualFunctions) returns final functions
- d-bugmail puremagic.com (24/24) Mar 12 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (16/16) Nov 16 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (9/9) Jan 21 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (10/10) Jan 21 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (13/13) Jan 21 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (13/13) Jan 21 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (14/16) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (21/21) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (8/8) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (9/9) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (9/9) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (15/18) Jan 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (8/8) Jan 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
- d-bugmail puremagic.com (11/14) Jan 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1918
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
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
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=1918 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yebblies gmail.comCould 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
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=1918Why 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
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
http://d.puremagic.com/issues/show_bug.cgi?id=1918final 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