D on quora ...

[Jonathan M Davis]

On Friday, October 06, 2017 21:39:21 Ali via Digitalmars-d wrote:
> On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
> > D's GC isn't going anywhere.
>
> Well, if I got the message correctly, it seems the key Dlang
> maintainers, are more sold on adding full support to
> Deterministic (manual) Memory management
>
> And a lot less sold on improving the existing GC
>
> So as I understand the current road map involve more work on
> Deterministic (manual) Memory management and a lot less work on
> improving the GC

There is definitely work being done towards improving more deterministic
forms of memory management, but there's also been work done towards
improving the GC. It just isn't talked about much.

And even some of the more deterministic memory management is still
potentially going to be using the GC (e.g. they've talked about introducing
better language support for reference counting but using the GC to take care
of cycles).

> And the requirement for the GC will be removed from the standard
> library

Some parts of the standard library will always require the GC. Much of it
does not. The idea is to avoid requiring the GC when it doesn't make sense
to require the GC, and there are cases where the GC is accidentally
required. For instance, on the whole, stuff like std.algorithm should not
use the GC and does not use the GC, but sometimes, when lambdas get
involved, closures end up being allocated, which means that the GC gets
used, and that may not have been intended or expected. Some of that can be
prevented, and some of it can't. Someone who wants to fully avoid the GC
probably will need to minimize passing lambdas to functions and prefer
functions or functors.

The main thing is that we need to ensure that the GC is not required when
it's not meant to be required. It has never been the plan to remove it from
Phobos completely. That really wouldn't make any sense, and in quite a few
cases, it literally can't be done (e.g. a number of functions were designed
to return newly allocated arrays; we can provide alternatives to them in a
number of cases, but we couldn't make the existing stuff not use the GC).

So, plenty of work still needs to be done to ensure that some stuff is
marked @nogc when it should be and ensure that the GC is not accidentally
used, but we're not stripping out the GC.

In some cases, it probably is just figuring out a way to make the
documentation clearer like Laeeth mentioned, but that can be a bit
entertaining given that whether something allocates is frequently a question
of what arguments it's given (e.g. very little in std.algorithm will ever
allocate if it's given a functor, but lots of it will allocate if it's given
a lambda or non-static nested function that the compiler decides might need
a closure allocated), and that can't really be covered by @nogc in the
documentation. You can use @nogc when you call it to ensure that you're not
triggering the GC, but it depends on what you passed, so it has to be
inferred rather than being explicitly documented as @nogc. And thus far, we
really haven't done anything to figure out how to document when whether
something uses the GC depends on what you pass it.

Regardless, I can absolutely guarantee that Walter and Andrei are not
planning to rip the GC out of everything. They just don't want to be
requiring it when we don't need to, and that's not something that Phobos has
always done a good job of, though a lot of the idioms it uses seriously
reduce GC usage.

- Jonathan M Davis