It's because the diamond problem. The diamond problem is purely an academic problem and it very seldom happens in the real world and if it does you probably did something wrong in your design. Happen to me once in 30 years because I messed up. Multiple inheritance is often flat, which means that one class inherits from several others at the same level. Instead of disallow multiple inheritance you can disallow the diamond pattern.

[snip]

It's because the diamond problem. The diamond problem is purely an academic problem and it very seldom happens in the real world and if it does you probably did something wrong in your design. Happen to me once in 30 years because I messed up. Multiple inheritance is often flat, which means that one class inherits from several others at the same level. Instead of disallow multiple inheritance you can disallow the diamond pattern.
[snip]

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

However, I was thinking what happens if you do something like
A ac = new C();

How would the compiler handle that?

On Tuesday, 22 June 2021 at 09:04:05 UTC, IGotD- wrote:

Some other language had suggested something like below as a solution to the diamond problem
class A { void a() {} }
class B : A {}
class C : A { @disable a; }
class D : B, C {}

However, I was thinking what happens if you do something like
A ac = new C();

How would the compiler handle that?

On Tuesday, 22 June 2021 at 02:13:33 UTC, zjh wrote:

It's because the diamond problem. The diamond problem is purely an academic problem and it very seldom happens in the real world and if it does you probably did something wrong in your design. Happen to me once in 30 years because I messed up.

Multiple inheritance is often flat, which means that one class inherits from several others at the same level. Instead of disallow multiple inheritance you can disallow the diamond pattern.

D went another way with composition with template mixins. Nothing particular wrong with this model but I think the D documentation isn't clear about its intended use. Also the overlap with alias this makes it more confusing.

[snip]

That language is called Eiffel, and in such case, C become abstract class, as I explained in this post:

https://forum.dlang.org/post/ztawxnwydbxiymcqvzhr@forum.dlang.org

https://forum.dlang.org/post/ztawxnwydbxiymcqvzhr@forum.dlang.org

On Tuesday, 22 June 2021 at 13:42:30 UTC, mw wrote:

Thanks, the name of the language wasn't coming to me but I recall the prior discussion.

So if C becomes abstract, then the above line is prevented because you cannot instantiate an abstract class (correct? I

can't test it on run.dlang.org right now and I'm not sure if it is C c = new C() that is prevented or this one). That's kind of limiting, no?

Does that have any separate implications for:

A ad = new D();
B bd = new D();
C cd = new D();
D dd = new D();

My thought would be that just cd would be prevented.

[snip]
Not at all. First it's by the programmer's design (if s/he chooses to do it in this way).

Second: to solve diamond problem, undefine / rename a feature usually happen in D:

Class D : B(disable a), C ｛｝ // so using C.a()

Class D : B, C(disable a) ｛｝ // so using B.a()

Note: this resolution in D, make A B C D all usable, non of them is abstract.

Please check my github example.
[snip]

What prevents unifying D classes with C++?