STL: Should we avoid repeating `virtual` for `override` functions?

[StephanTLavavej]

Currently, we follow a convention of saying both virtual and override on derived implementations. One of many examples:

STL/stl/inc/functional

Lines 861 to 863 in 58bb49d

	virtual _Rx _Do_call(_Types&&... _Args) override { // call wrapped function
	return _Invoker_ret<_Rx>::_Call(_Mypair._Myval2, _STD forward<_Types>(_Args)...);
	}

We started doing this when override was new and we weren't familiar with reading it. Now that we are, should we avoid this redundancy? The advantage to doing so, aside from reducing verbosity, is that it would make the remaining virtual occurrences stand out. Those indicate either base declarations, or derived implementations that should be marked override (see #207 for that).

[ChrisGuzak]

this is what C.128 says to do. go for it.

[MikeGitb]

Has there ever been a proposal to allow override before the declaration of a function? Imho, having a visual clue consistently at the front is the only advantage of using both virtual and override.

[StephanTLavavej]

According to my understanding, that would conflict with override's status as a context-sensitive keyword. In C++11 through C++20, you can have struct override, and that can appear as a return type of a function: override meow(int).

[MikeGitb]

Urgs. Makes sense :(.
Thanks

[AlexGuteniev]

I think that it makes sense to decide towards removal of superfluous virtual and address #207 with clang-tidy.

See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html

I'm not sure however how to integrate this into build.

[StephanTLavavej]

We've decided - let's go ahead and use override only! 🎉