On Wed, 12 Mar 2014 09:15:14 -0400, Michel Fortin
<michel.for...@michelf.ca> wrote:
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.
OK, I can see that being useful. You are right, I was thinking C++ private.
So essentially, a virtual private function can only be overridden in
classes defined in the same module. What happens when you do it in a
separate module, an error? What if you want to define that function name,
but it's taken by the base class, what happens?
-Steve
