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. [...]
>
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?
True, these are the common cases, but nevertheless, something along these lines can be helpful.
Consider the even more complicated and, well, disagreeable, case of multiple inheritance with the diamond pattern, virtual inheritance and all. If the final derived class calls its two (or more) bases, and each in turn calls the shared base, then the shared base is called twice while in reality it should have been called once. An automated generation of the call sequence could remedy this.
I am proposing two mechanisms for these common cases in the hope that this is where it stops. Had there been more than two cases, then the idea does seem somewhat futile. But IMHO these two cases are common enough and important enough to look at anyhow.
For the rest, unfortunately, I don't have a better offer than using the existing virtual method mechanism as is. I don't see a way to generalize beyond the two.
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.
My goal is that the "extensible" nature of the method would be _declared_ at the base class. Being declared, the question of whether to issue a warning is almost secondary. Because, as many of us treat warnings as errors, we'd have to solve the issue of missing the explicit call one way or another. By that time, we'd beg for an automatic solution.
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.
I would not say it's overwhelming, but the issue with the diamond pattern does look to me like a stronger 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.
These, indeed, are two different issues. To me, actually, the first looks more acute. But I might split a proposal if it becomes such.
--
Matthew
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals