What are the prominent downsides of the D programming language?

[Jean-Louis Leroy]

On Wednesday, 30 September 2020 at 00:28:34 UTC, H. S. Teoh wrote:
> On Tue, Sep 29, 2020 at 05:13:31PM -0700, Walter Bright via 
> Digitalmars-d wrote:
>> On 9/29/2020 2:56 AM, Petar Kirov [ZombineDev] wrote:
>> > I don't have experience with multiple inheritance in Eiffel, 
>> > but it would be shame that in a language with `static if`, 
>> > `mixin template`s, `static foreach`, etc. we can't figure 
>> > out a way to make it work.
>
> I betcha you could do it as a library. ;-)
>
>
>> The more interesting question is "is it worthwhile to make it 
>> work?" No.
>> 
>> Too many paths to implicit conversions (and that's really what 
>> MI is)
>> leads to nothing but confusion.
> [...]
>
> Yeah, after many years of loving to sprinkle alias this 
> everywhere, I'm starting to realize that it's not such a good 
> idea after all. It leads to code that looks like it's correct, 
> but actually it does something else. Give it a few more 
> iterations of refactoring, bugfixes, and feature additions, and 
> the code quickly becomes totally opaque and hard to reason 
> about. Or just plain ugly because the data structures have 
> turned into a Frankenstein monster where sometimes it's type A, 
> sometimes it's type B, and you have to insert random shunts 
> everywhere to interconvert between them where implicit 
> conversion didn't happen automatically.

Well...at work my team uses C++ multiple inheritance in our main 
product, which is massively event-oriented and multi-threaded. 
Not tons of it but where we use it, the alternatives would be 
more verbose, less readable, slower, more complicated. The couple 
of cases I have in mind right now involve hierarchies that are 
orthogonal. There are no diamonds, because they would make no 
sense at all. So, better code and no headaches. Who could object 
to this?

There is a pattern that I have observed in my 30+ year career, 
it's not easy to phrase it, but it goes something like this: when 
I found MI handy, it was usually for mixing independent technical 
aspects, not so much "modeling the real world". I think that 
someone mentioned a Button that is both a Drawable and a 
Clickable. This is the sort of things I have in mind. And if you 
don't use MI you quickly get a god class that declares dozens of 
facets, only a few of which are actually implemented in classes 
scattered across the inheritance tree (think the Microsoft 
Foundation Classes with its CObject god class).

I also have had success with CLOS-like mixins: small bits of 
implementation that could be combined easily (of course this is 
in cases where the combination does not change at runtime), 
resorting in C++ virtual inheritance and the dominance rule. And 
this time, diamonds were at the core of the design. Again MI felt 
like a handy way of organizing my code on a local scale, rather 
than some ground shaking, mind-opening big statement about "the 
world" that would open the path to magically cost-free endlessly 
reusable code.