On 2014-03-12 03:04:38 +0000, Manu <[email protected]> said:
virtual-by-default is incompatible with optimisation, and it's reliable to
assume that anybody who doesn't explicitly care about this will stick with
the default, which means many potentially useful libraries may be
eliminated for use by many customers.
I'll add another argument to the mix.
Currently, you can't have private/package functions that are virtual,
contrary to what TDPL says.
To make things coherent we could change private function so they become
virtual by default. You might be able to see the problem with this
option: making private function virtual by default is likely to add
many performance regressions in existing code, silently.
Or we could implement final by default. This option would instead force
people to add 'virtual' here and there, but otherwise existing code is
likely to run faster after that.
We could always keep things as they currently are: private/package is
not virtual, everything else is virtual unless marked final. Honestly
I'd like to se that go. The protection attribute should have nothing to
do with whether a function is virtual or not.
--
Michel Fortin
[email protected]
http://michelf.ca
