On 19/05/2019 05.02, Ofri Sadowsky via Std-Proposals wrote:
> 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.

But how would *that* work?

Let's say we have A : B, C; B: D; C : D.

In order to call D::foo() only once, the compiler would have to generate
*two* versions of B::foo() and C::foo(); one that auto-calls D::foo()
and one that doesn't. I think this would only work if derived methods
*only* ever call the versions that don't auto-call bases.

That said, as you later mentioned (snipped), I could see this being a
better motivation than the more general case.

> 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.

Again, what about the case that I need to call the base implementation
in the middle of my derived implementation? What about the case that the
method returns something, and the derived implementation needs to use or
modify that return value?

I'm concerned that pure-head and pure-tail only cover a fraction of use
cases. I'm also concerned that the rest of the committee will feel that
the work of adding a language feature does not justify the purported
benefit, when a compiler warning would achieve most of the benefit with
far less cost.

-- 
Matthew