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
- 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 from the old D1 page:
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".