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.
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.
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
Could you please explain how a final function that doesn't override anything is ever supposed to be virtual?
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.
(In reply to comment #3) > 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.
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.
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
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
(In reply to comment #6) > 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.
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.
(In reply to comment #10) > 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.