On Tuesday, 22 June 2021 at 16:13:11 UTC, jmh530 wrote:

https://github.com/mingwugmail/dlang_tour/tree/master/eiffel/visitor

On Tuesday, 22 June 2021 at 16:17:58 UTC, Guillaume Piolat wrote:

There are books for everything. The C++ runtime model isn't all that complicated.

On Tuesday, 22 June 2021 at 15:14:02 UTC, mw wrote:

I don't really see the difference between this and forcing a reimplementation of a() that calls A's a(), B's a() or both.

On Wednesday, 23 June 2021 at 17:00:00 UTC, Ola Fosheim Grøstad wrote:

There is nothing magic (which is a bad thing ^TM :-) about Eiffel's multiple inheritance.

This demonstrate: MI can be done, and with the compiler's help, it can be done more easily.

That's all.

(I think we both are all arguing for MI be included in D, right :-)

On Wednesday, 23 June 2021 at 17:12:38 UTC, mw wrote:

-Alex

On Monday, 21 June 2021 at 19:56:50 UTC, Meta wrote:

Multiple inheritance induces a lot of headaches (added complexity, diamond inheritance, etc.), and even C++ devs try to avoid it at all costs. It rarely has any real-life use, that couldn't be solved with interfaces and mixins.

On Monday, 28 June 2021 at 20:35:25 UTC, solidstate1991 wrote:

That isn't the point (if it is true). And actually, C++ stdlib uses it. Some C++ devs avoid virtual in general though, but that is another issue.

The point is that you need multiple inheritance to unify D classes with C++ classes, but you don't have to use it if you don' want to, so there is no cost to having it. So basically only one big benefit, and no real disadvantages.

On Monday, 28 June 2021 at 21:03:21 UTC, Ola Fosheim Grøstad wrote:

We Technically have multiple inheritance in d via alias this, so that cat is out of the bag. I just wish walter would bite the bullet and implemented multiple inheritance properly, so that we could deprecate alias this as it is a redundant feature.

• Alex

On Monday, 28 June 2021 at 21:03:21 UTC, Ola Fosheim Grøstad wrote:

Making a new feature optional does not, of course, actually make it free. The cost includes, minimally, the cost of implementation and maintenance over the life of the compiler(s) and the debugging costs incurred by programmers encountering bugs in the, potentially complex, new compiler code.

OTOH, if a feature addition provides a new best-practices capability that displaces error prone coding going forward, then the benefits could very well outweigh such costs over time. I'm hopeful that this is true of the template free metaprogramming additions proposed recently. I'm less hopeful regarding MI.

On Monday, 28 June 2021 at 23:17:36 UTC, Bruce Carneal wrote:

The complexity that comes with multiple inheritance is the offset to the ancestor class, but that is already solved by the C++ ABI one chooses to conform to.

The diamond problem isn't about what to do when merging members, which seem to have been what people have focused on in this thread, but whether you want the common ancestor A to have two instances or one instance. So in C++ you solve this by making the shared ancestor virtual if you want to have one ancestor instance. Which is a bit clumsy, but I guess this comes down to requirements inherited from C-style separate compilation.

Still, C++ is what it is, so compilers have to deal with it regardless. Unifying C++ and D classes gets rid of one language construct (The D class). So it does make the language simpler for the user in my view.