On Wednesday, 2 June 2021 at 14:02:29 UTC, Mike Parker wrote:

I thought v2 is what it currently is, so the next would be v3.

On Friday, 4 June 2021 at 13:32:37 UTC, Ola Fosheim Grøstad wrote:

You might be surprised, but it's actually not up to you what topic fits or not.

I said GC-phobia is irrational, I did not say any criticism of it is.
Obviously GC is good for some things and not good at all for other things.

What is irrational is saying it has absolutely no place at all.

On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:

I don't think it is a phobia but it is a question of choice. We can clearly observe how different the demands are for different programmers in this forum. I enjoy GC for the appropriate programs, however there are SW where GC is a problem and cannot be used. Because of this Phobos must take the lowest common denominator approach (malloc/free) in order to be able to accommodate all the different needs.

D is one these Swiss army knife languages that can be used for everything, including low level software and everything in between. What D should strive for is to give programmers a choice and put up as few barriers as possible. It's certainly challenging to make a library and language fitting everyone needs but D is at least one of the best foundation of achieving that goal.

On Friday, 4 June 2021 at 19:31:57 UTC, IGotD- wrote:

This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection.
You can parametrize over all possible MM strategies making every function generic and pass the right MM into it.
Beside increasing template bloat it isn't that optimal as the same code has different performance characteristic for each MM, so you need to overload over all these and even then you won't cover all the MM because there are people wanting to insert their custom MM, but the library was already written.

I'm asking myself, even if we don't care about the cons, would that at all be possible with a ~20 years old language with a ~20 years of ecosystem evolution. How many things need to be rewritten?

On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote:

This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory.

In the case of Phobos, in order to make as versatile as possible it shall not assume any other layer than malloc/free.

D certainly has the power to do so but the question is if there is any will power in this community. Nothing has happened for almost 20 years.

On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:

I guess importC will make changes even more unlikely. Absorbing C is nice, but it has the unfortunate effect of giving D some of the same disadvantages as C++.

On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:

This is the announce forum, so it is kinda misplaced, but we are all contributing to this so... :)

The problem is that the D-style GC is not a good fit for anything interactive, beyond simple applications.

My impression is that most people use D for batch programs, so I guess that shapes the opinion. And that is a problem for D. A bad GC-strategy is reinforced by the remaining majority, which is a tiny fraction of the overall programming community.

These days you don't really need a system level language to write batch programs. So it is not a good strategy to hold onto this specific type of stop-everything-scan-everything GC. Unless D decides to not be a system level language, but then you need a lot more convenience features and become more scripty. The inbetween position is not the top-pick for anyone looking for a solution.

Not being willing to switch MM strategy means being stuck on a tiny island, too afraid of crossing the ocean to get access to the main land. My impression is that Walter would rather stay on this tiny island than take any chances.

The language is being extended with incomplete experimental features, instead of going to the core of the issue and doing something with the foundation for the language. That is not going to end well. You'll end up with a patchwork.