private/package methods cannot be virtual

[Idan Arye]

On Monday, 6 May 2013 at 19:05:04 UTC, deadalnix wrote:
> On Monday, 6 May 2013 at 18:44:07 UTC, Jonathan M Davis wrote:
>> On Monday, May 06, 2013 14:19:12 Henning Pohl wrote:
>>> Documentation:
>>> Member functions which are private or package are never 
>>> virtual,
>>> and hence cannot be overridden.
>>> 
>>> I was about to write a bug report about this, because in my 
>>> code
>>> there are tons of overridden methods which actually should be
>>> private/package. Can anyone tell me why this decision has been
>>> made? To inline them?
>>> 
>>> Do I really need to write interfaces to be able to override 
>>> these
>>> methods?
>>
>> The decision was made to make member functions virtual by 
>> default. As soon as
>> that function was made, there had to be a choice for every 
>> access level as to
>> whether it would be virtual or not. public and protected 
>> obviously have to be
>> virtual, and in general, there's no real benefit in making 
>> private virtual (and
>> there's a definite permorfance cost to programs in general if 
>> you do), so it's
>> non-virtual. There's a bit of disagreement with regards to 
>> package, but it was
>> decided that it wouldn't be virtual either, as it had nothing 
>> to do with
>> inheritance.
>>
>
> If it is private, by definition, the compiler have all override 
> available. So it can finalize automatically.

This is usually true with `package` - modules that belong to the 
same package are usually compiled together. Ofcourse, unlike 
`private` it is possible to add your own module to an existing 
package from another library(at least namespace-wise), but I 
guess it's not that common.