Yes, I'm also saying,
If you can insert memory management as a template parameter, that's good.
Just like C++,c++'slater memory management improvements benefited from it.

I have come to the conclusion that the fighting power of language is:
C++~d>trust~C#>KT,Java,go. Ifd is afraid of improve and adheres to GC, I will move d to the end and directly choose C++ becaused retains disadvantages and gives up advantages. Because there are many places wherememory is very important. The lessmemory means the less cost. Only in this way, industrial users will choose you.

At present, c++'s comprehensive strength is the strongest .

If we make BIG changes, we can change it to better c++.

since d has much fewer users, it can be either a disadvantage or an advantage. Because you can be confident and bold to make changes. When you have more users, you are really constrained. This is where C++ can't beat d.

not trust,but Rust.
Translation problems.

On Wednesday, 19 May 2021 at 00:21:11 UTC, zjh wrote:

Good bye. Best of luck to you on your project.

On Wednesday, 19 May 2021 at 00:21:11 UTC, zjh wrote:

This thread is D and has been for the last 10+yrs.

Changing requires effort but unfortunately the louder someone bitches and moans on the forum the less effort they seem to be willing to put in to fixing the issues they have. You can contribute your ideas with PRs and DIPs today, or you can fork the compiler and create PDAY, Perfect D According to You.

But both require effort other than the hot air been blown all over the newsgroup.

The other alternative is, as you say, go to C++. This is what I did a while back and now I use C++20 for most projects. For me personally D kinda stalled in terms of what I was looking for and started chasing the tail of Rust. So I may as well use C++20 and beyond, which has or will have most of the features that originally drew me to D.

D really doesn't have to worry about being a C++, Java, C#, Rust, Go killer language. All that is just a distraction.

On Wednesday, 19 May 2021 at 03:11:15 UTC, norm wrote:

On Wednesday, 19 May 2021 at 03:11:15 UTC, norm wrote:

But back to the OP, it would be interesting to see quarterly roadmaps published for D on the wiki. It doesn't matter if most items are dropped or never implemented, what it provides for the community is a snapshot of what the core team are working on and their near term plans at the time of writing. If it changes by next quarter, who cares it is still of interest.

At least you have to know D's road map, D's development expectation and D's self position, so that you can work accordingly.
Otherwise, it will be a blind toss.

When everyone is pulling D towardsC++/Java/Python/go, it's useless if you want to pull C++. Can you wake them up without saying it aloud?
D need a sense of urgency. Really, when C++23 is comming, reflection / network is available. Even you are trying to use C++. where is D's place?

towards C#/Java/Python/go
one translate,ten errors.too funny.

On Wednesday, 19 May 2021 at 03:11:15 UTC, norm wrote:

No, it is important to build common ground and make people understand key issues that the language has and make sure these ideas are understood and internalized. It is also important to get a wide variety of options on the table. D has been chasing the tail of other languages too much, it needs its own ideas. DIPs have limited value, because of veto power, you need preapproval + common ground. How do you make common ground without using the forums? You can use chat I guess, but that is very time consuming.

I am happy to see that some of the key issues I have had with the language is on the table now. I will probably write a DIP about type unification if nobody else beats me to it, but it should wait till after the most important weakness, memory management, is dealt with. So that DIP can wait... No point in shifting focus now, as memory management is difficult to get right in a competetive manner. Atila confirming that MM is on the plan was good to hear.

Yeah, I fork, but the compiler needs restructuring after 20 years, like most software. It is currently "resistant to change" . Changing is still possible, but how do I rebase? The current structure limits how much you ought to change, so I only change stable parts... So my fork is in limbo until I am bored enough to find rebasing entertaining, probably october...

I mean I could restructure DMD myself, but how would I then get the DMD changes in?