Future of memory management in D

[rumbu]

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.

> 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);
* struct inheritance
* explicit interface implementations
* class destructuring
* properties
* pattern matching on class type
* pattern matching on fields/properties
* implicit constructors

>
>> Now, without a gc, more than half of the language risks to 
>> become unusable and that's why I ask myself how do you see the 
>> future of the memory management in D?
>
> The GC isn't going anywhere. It's the easiest way to write 
> memory-safe code other than leaking everything.

Personnaly I want gc to stay and improve. But when I see the 
language trying its best to please the gc haters, I wonder if the 
GC is the right default memory management in D. That was in fact 
the main idea of this post, which model of memory management will 
be more suitable to be assumed in D to make everyone happy.

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".