• Henning Pohl (9/9) May 06 2013 Documentation:
• Jonathan M Davis (20/31) May 06 2013 The decision was made to make member functions virtual by default. As so...
• deadalnix (3/33) May 06 2013 If it is private, by definition, the compiler have all override
• Idan Arye (6/41) May 06 2013 This is usually true with `package` - modules that belong to the
• Jonathan M Davis (9/11) May 06 2013 Not with the current spec. As it stands, private is not hidden, merely
• Dicebot (4/11) May 07 2013 I suppose you have meant override sets. I have written DIP to

"Henning Pohl" <henning still-hidden.de> writes:

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?

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

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.

There's actually quite a bit of disagreement on whether member functions 
should be virtual by default (in particular, the guys working at companies 
which need high performance really don't like it), but at least for the 
moment, that's the way it is. And in order to make private or package 
functions virtual, we'd need a way to do so explicitly, which we don't 
currently have.

I'm considering creating a DIP on the matter, but I think that I'm going to 
wait until some of the current discussions die off; otherwise it wouldn't get 
the attention that it deserves (the rvalue discussion in particular is likely 
to be quite large).

- Jonathan M Davis

"deadalnix" <deadalnix gmail.com> writes:

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.

"Idan Arye" <GenericNPC gmail.com> writes:

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.

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Monday, May 06, 2013 21:05:03 deadalnix wrote:
 If it is private, by definition, the compiler have all override
 available. So it can finalize automatically.

Not with the current spec. As it stands, private is not hidden, merely 
inaccessible. So, if private were to become virtual, derived classes in other 
libraries could override it. That's how it works in C++.

Now, quite a few of us would like private to become hidden from overload sets 
(which would then make it so that what you suggest could work) and make it so 
that nothing outside the module could override it even if it were virtual, but 
that's not how it is now.

- Jonathan M Davis

"Dicebot" <m.strashun gmail.com> writes:

On Monday, 6 May 2013 at 22:25:06 UTC, Jonathan M Davis wrote:
 Now, quite a few of us would like private to become hidden from 
 overload sets
 (which would then make it so that what you suggest could work) 
 and make it so
 that nothing outside the module could override it even if it 
 were virtual, but
 that's not how it is now.

I suppose you have meant override sets. I have written DIP to 
remove them for overload sets but AFAIR override issue was not 
mentioned. Probably should as it is not that much different.