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
