On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov
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
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.