On 17/05/2019 05.23, Ofri Sadowsky via Std-Proposals wrote:
> This post is based on an experience which, I believe, is shared by many,
> having to do with the concept of "extending" a base class rather than
> "overriding" its functionality. [...]
>
> In current language [...] it requires the developer to explicitly
> make the call to the base class method, with the risk of missing it.> In principle, the existing compiler mechanism could also support
> something such as the following.
>
> class Base
> {
> public:
> tail_extensible void setup()
> {
> // do some setup
> }
>
> head_extensible void cleanup()
> {
> // do some cleanup
> }
> };
>
> class Derived
> {
> public:
> void setup() extension
> {
> // Base::setup() is called automatically
> // do my own setup
> }
>
> void cleanup() extension
> {
> // do my own cleanup
> // Base::cleanup is called automatically
> }
> };

I think the fact that you are already proposing two different mechanisms
for this hints at why this is problematic and, IMHO, unlikely to go
anywhere. The trouble is, you're handling the fairly common cases, but
what about the less common cases? What about if the overriding method
needs to use neither of those patterns or, worse, needs to call the base
method conditionally?

I think it would be much more productive to pursue a de facto mechanism
to mark a virtual method for which the base implementation should always
be called, and for the compiler to issue a warning if it is not.
Possibly this should be combined with an annotation to indicate
intentionally not calling the base method.

This *might* be combined with a new syntax to make it easier to invoke
the base method (including argument forwarding), though the committee
tends to be resistant to such things without overwhelming motivation.

> Second: It sometimes happens that I want to extend an existing class
> with functionality only [...] the extending class cannot define new
> members (maybe more relaxed for static members), and in return it
> does not have to specify all the mechanism of construction and
> assignment, which is inherited from the base class.
Conversely, I've run into this on multiple occasions. I think this could
be useful, and should probably be pursued as a separate proposal.

-- 
Matthew