private is non-virtual: Stuck in C++-thinking?

[Jonathan M Davis]

On Tuesday, October 23, 2012 21:34:35 deadalnix wrote:
> Le 20/10/2012 01:14, Jonathan M Davis a écrit :
> > On Friday, October 19, 2012 23:22:26 monarch_dodra wrote:
> >> According to TDPL, this should be legal. In particular, there is
> >> an entire section about it regarding NVI.
> >> 
> >> No idea what it going on, but I'm curious for answers.
> > 
> > For interfaces, where it's doing something to specifically enable NVI. It
> > never says that for classes.
> > 
> > It's been discussed a number of times before, and I think that it's fairly
> > clear that Walter has no intention of changing it. Regardless, it would
> > actually be a _huge_ problem for private to be virtual, and it's
> > completely
> > unnecessary for NVI (protected does the job just fine). If private were
> > virtual, then it that would kill inlining and any other optimization
> > relying on knowing the body of the function or anything else which gets
> > affected by a function being virtual - including the cost of the vtable
> > lookup.
> 
> Yes, if you don't want that, just define this a a private free function.
> D isn't some kind of language where everything need to be an object.

That's no better than expecting programmers to mark all of their private 
functions final. It's not what they'll do normally, so they'll end up with 
slower code and complain about it. It just makes things slow by default, and 
being able to override private functions gains you pretty much _nothing_. 
_All_ that it does is make it impossible to call the base class implementation 
of the function. You can still call the implementation in the derived class. 
protected will do _exactly_ the same thing for you except that derived classes 
will be able to call the base class implementation rather than just their own.
Making it impossible to call the base class implementation isn't even vaguely
worth the performance costs that then affects almost every class ever written
in D.

- Jonathan M Davis