D Language Foundation Monthly Meeting Summary

[IGotD-]

On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote:
>
> I think the switch to arc with cycle detection as opt out (like 
> in python) is the right direction, it fits more to a system 
> level language making use of destructors more often.
>
> Rewriting cyclic code to acyclic code is easier than lifetime 
> management in general.
>
> Further, optimizations can be introduced that detect acyclic 
> structures in D just as it is the case for nim 
> (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma).
>
> That doesn't mean tracing GC is bad, I'm still skeptical that 
> arc + cycle detection is better than tracing in general for 
> true high level languages.

Yes, this is a way forward. Walter doesn't want to add fat 
pointers, however he hasn't mentioned if that's part of the 
language or fat pointers as a library (like C++). It doesn't need 
to be part of the language but as a library type. Classes in D 
are essentially already library fat pointers. What we need is to 
extend this so that we have a generic fat pointer type (that can 
be recompiled to whatever GC type we want) that can be used for 
any type through out the entire code base if the programmer 
wishes that. Then we need refactor druntime/phobos to only use 
this fat pointer type.

As you mentioned, in order to have better support for different 
GC, we can support compiler hooks (like your acyclic example) in 
order to give the compiler optimization hints.

Whatever GC type you think is better for you, you should decide 
that and not forced by the D compiler and library. Basically GC X 
is better than Y is not an argument. What is the argument is how 
we can allow people to choose.