D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Sunday, 4 October 2015 at 18:02:21 UTC, bitwise wrote:
> There are several things in phobos that are classes. This goes 
> against the nogc goal, so what's the plan?

It is not the goal to eliminate GC usage entirely. It's not like 
we're getting rid of the GC. Rather, it's the goal to make it so 
that the GC is not used when it's not necessary and to minimize 
how much it's necessary. Some things will always require 
polymorphism and classes, and in at least some of those cases, 
that means using the GC. And features like appending to arrays or 
allocating closures will always require the GC. We just need to 
make sure that those features aren't used when they're not 
actually needed.

Now, Walter and Andrei have talked about adding some sort of 
reference counting to the language so that we can support a class 
hierarchy that's specifically reference-counted (exceptions in 
particular would be a target for that) - though that doesn't 
necessarily mean that they won't use the GC, just that their 
destruction will be deterministic. And std.allocator should make 
it easier to use classes without the GC. So, the situation with 
classes and the GC will be improving.

And not much in Phobos uses classes anyway. There are a few cases 
where it does and probably shouldn't (e.g. std.mmfile probably 
shouldn't be using class, since no polymorphism is required), but 
most of Phobos has used structs for ages, and a few places 
actually need classes to provide the functionality that it 
provides. The biggest GC problem in Phobos is probably how often 
you end up with closures being allocated for algorithms, 
particularly since it's invisible unless you use @nogc. And that 
definitely needs to be resolved. The second is probably how many 
functions return strings instead of lazy ranges, and work has 
been done on that, though there's still more to do. But classes 
are a very small part of Phobos.

- Jonathan M Davis