What are the prominent downsides of the D programming language?

[mw]

On Tuesday, 29 September 2020 at 22:02:28 UTC, Jean-Louis Leroy 
wrote:
> On Tuesday, 29 September 2020 at 21:43:03 UTC, mw wrote:
>> The key idea is to treat each parent's class attributes 
>> individually (via rename/undefine/redefine/select) instead of 
>> as in other multiple inheritance languages, e.g. C++'s 
>> all-or-none approach, i.e. either all the parents' attributes 
>> are shared or separated, and even when separated, there is no 
>> proper renaming mechanism to handle it.
>
> If Base has features f and g, and Derived inherits from Base 
> but undefines g, I assume that a Derived object cannot be 
> substituted for a Base. Correct?

It still can; but the Derived now becomes a deferred- (in D's 
term abstract-) class.

because Derived.g becomes a deferred- (in D's term abstract-) 
method.


This is the demo:

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

https://github.com/mingwugmail/dlang_tour/blob/master/eiffel/mi/us_resident.e#L3
   undefine addr

https://github.com/mingwugmail/dlang_tour/blob/master/eiffel/mi/app.e#L17
   create usr.make  -- ****** Warning: addr is a deferred feature 
in US_RESIDENT.

https://github.com/mingwugmail/dlang_tour/blob/master/eiffel/mi/app.e#L11
    print_addr(p: PERSON) is do
       io.put_string(p.addr + "%N")
    end



NOTE: I'm not sure if the SmartEiffel compiler is implemented 
correctly, it generate warning instead of error, during 
compilation:

$ make
compile  app.e -o app
****** Warning: addr is a deferred feature in US_RESIDENT.

And if you run it, it error out:

$ ./app
*** Error at Run Time ***: Deferred routine called.
4 frames in current stack.


Ideally, this program shouldn't compile; since it detected that 
we are trying to create an object of a abstract (deferred) class.


Hey, just download the SmartEiffel compiler, and try the demo :-) 
it's all in the same repo:

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