What are the prominent downsides of the D programming language?

[Petar]

On Monday, 28 September 2020 at 18:42:36 UTC, H. S. Teoh wrote:
> On Mon, Sep 28, 2020 at 06:12:16PM +0000, mw via Digitalmars-d 
> wrote:
>> On Monday, 21 September 2020 at 10:42:55 UTC, Walter Bright 
>> wrote:
>> > On 9/21/2020 2:35 AM, Ruby The Roobster wrote:
>> > > One downside is that classes can't inherit from multiple 
>> > > classes.
>> > 
>> > That's a feature, not a downside. I'm not joking.
>> 
>> As you admitted some time earlier, the other mechanisms such 
>> as sub-typing, mixin has effectively introduced multiple 
>> inheritance into D already.
>
> Yes, and we're already regretting it.  As it turns out, alias 
> this (one of the ways to do multiple inheritance in D) has 
> quite a few nasty corner cases that cannot be (easily) 
> reconciled, and now we're starting to discourage its use.  How 
> to resolve identifier lookups when there are conflicts, etc..  
> There's always a way to rationalize your way out of it; but at 
> the end of the day, it leads to confusing, hard-to-remember, 
> arbitrary rules that have counterintuitive corner cases.

I'd say the main reason we may be "regretting" `alias this` 
(though I wouldn't go as far as say "regretting") is that it 
wasn't designed systematically enough (with consideration of it's 
interaction with other features) and also at time the language 
was very free floating (some parts of the language were still 
being changed and tweaked quite often).

I suggest you re-read the old posts from the DIP66 thread. I 
think principled solutions to quite a few of the issues with 
multiple alias this were found.

>
>> > Multiple inheritance is a horrible abstraction, all it does 
>> > is confuse people.
>> 
>> Well, if it's designed or implemented poorly in the language.
>
> If you have a *workable* idea of how to do it *in D*, we'd love 
> to hear it.  I'm not holding my breath, though.
>
> Don't get me wrong; I love alias this and use it a lot myself. 
> But over the years, I'm gradually beginning to see where it 
> leads to problems. It's useful as a quick hack or shunt to 
> bridge two subsystems that are kinda but not quite compatible, 
> or to shoehorn implicit conversions into a user-defined type, 
> but in the long term, it leads to code smells. (Implicit 
> conversions are another of those things that sounds like a good 
> idea, is convenient to use, but in the long term leads to poor 
> maintainability.)
>
>
> T

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 think one extravagant, but definetely workable solution would 
be create a template DSL (ofc it could also be string 
mixin-based) in D to prototype a multiple
inheritance system (with e.g. the Eiffel features `rename`, 
`export`, `undefine`, `redefine` / `override`, and `select`). 
Being just a prototype, it should be acceptable to go with custom 
functions like `isSubTypeOf`, `asBaseType`, etc., instead of 
using the built-in language syntax and semantics. (Sort of like 
https://code.dlang.org/packages/openmethods adds multiple 
dispatch.)