On 2014-03-12 12:48:59 +0000, "Steven Schveighoffer"
<schvei...@yahoo.com> said:
On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin
<michel.for...@michelf.ca> wrote:
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.
Private virtual functions make 0 sense. A private function cannot be
accessed by a derived class. Who gets to access a overriden virtual
function? The base class only? If I'm writing a function, I certainly
should be able to access it, no? Even if you want to restrict my
access, you cannot, I'm in control of that code!
You're mixing C++ private with D private. Private just means the symbol
is only accessible within the same module. You can have a whole class
hierarchy in a module if you want, and thus could override private
functions assuming they could be virtual.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
