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, b
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 cl
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 ab
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
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 shou
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
