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.
Inheritance (subtyping) and value types don't mix.
- explicit interface implementations
- class destructuring
Could you please explain what these mean?
- 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 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".
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.