Broken?

[Michel Fortin]

On 2014-03-12 03:04:38 +0000, Manu <turkeyman at gmail.com> 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
michel.fortin at michelf.ca
http://michelf.ca