Future of memory management in D

[Atila Neves]

On Thursday, 18 November 2021 at 04:24:56 UTC, rumbu wrote:
> On Wednesday, 17 November 2021 at 21:46:45 UTC, Atila Neves 
> wrote:
>> On Tuesday, 16 November 2021 at 18:17:29 UTC, Rumbu wrote:
>>> At least from my point of view, it seems that recently D made 
>>> a shift from a general purpose language to a C successor,
>>
>> I mean, it kind of always was, which is even indicated in the 
>> name.
>
> I am here  when D was advertised as a general purpose language. 
> The last development efforts are concentrated around making a 
> better C, not a better D.

I don't see "a better C" and "a general purpose language" as 
mutually exclusive. Do you disagree?

>
>> Where would you say D has failed to evolve in terms of OOP?
>
> * wrong idea of what private means (yes, I know that you 
> disagree on that, but every OOP book/study/reference considers 
> the class as unit of encapsulation);

As you've mentioned, we're not going to agree. I don't think this 
is failing to evolve either since it's by design.

> * struct inheritance

Inheritance (subtyping) and value types don't mix.

> * explicit interface implementations
> * class destructuring

Could you please explain what these mean?

> * properties

What's missing?

> * pattern matching on class type

AFAIC this is an anti-pattern. IMHO, in OOP, there should be a 
switch exactly in one place in the program, and that's where 
instances get created. I don't know why anyone would want to 
recreate the functionality of the virtual table in an ad-hoc way.

Multiple dispatch blurs this, however.

> * pattern matching on fields/properties

How would this work?

> Personnaly I want gc to stay and improve. But when I see the 
> language trying its best to please the gc haters,

In my view it's not really about pleasing the GC haters as much 
as it's acknowledging that the GC isn't always the best choice, 
and making sure that we can write memory-safe programs without it.

> I wonder if the GC is the right default memory management in D.

I believe it is, yes.

> Finally, I found 
> [something](https://digitalmars.com/d/1.0/builtin.html) from 
> the old D1 page:
>
>>Complex Numbers
>>A detailed comparison with C++'s std::complex.
>>
>>The most compelling reason is compatibility with C's imaginary 
>>and complex floating point >types. Next, is the ability to have 
>>imaginary floating point literals. Isn't:
>>
>>c = (6 + 2i - 1 + 3i) / 3i;
>>far preferable than writing:
>>
>>c = (complex!(double)(6,2) + complex!(double)(-1,3)) / 
>>complex!(double)(0,3);
>>? It's no contest.
>
> 15 years ago. I will reply  with this quote to everyone who has 
> "another library solution".

Library solution:

auto c = (6 + 2.i - 1 + 3.i) / 3.i;

I'd disagree it's "no contest". I think that 2021 Walter would 
disagree as well but he can disprove me here if not the case.