On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov [ZombineDev] wrote:

The right answer is three fold:
A) Examples of idiomatic D code - generic functions agnostic about the memory management strategy like range algorithms;

B) Having solid tools at the language-level for implementing correct and relatively easy-to-use library primitives like smart pointers and containers - @safe + pure + scope.

C) Maintaining a list of functions/modules/third-party libraries that are usable in @nogc land.

But most of all, the focus should be on productivity and ease-of-use, because otherwise people tend to get the impression: TL;DR this is too complicated for me -> I can't use D without the GC -> Using D without the GC is not feasible.

Thanks! I agree that we need a range of posts on the GC. That's the whole point of the series. I have a set of posts I can write on topics within my current realm of knowledge, or that I can beef up on when the time comes, but beyond that I'm not the right guy to author some of the posts that need to be written. I haven't familiarized myself with all the corners, nor have I written any code that required me to push the boundaries or explore the possibilities.

A while back, I posted an announcement here explaining my goals with the GC series and asking for contributors. Aside from Atila's automem post, I haven't gotten any takers yet. I can, if need be, eventually write many of the posts I'd like to have, but that requires making time to familiarize myself with the topics. Such posts will also compete with those I plan to write on other topics.

So, in the interest of saving me a bit of time, I invite you and anyone who's willing to share their experiences and expertise with the GC. I'll happily publish any post that demonstrates allocation strategies, lifetime management, optimizations, or just generally helps to clear up misconceptions.

Reply via email to