Leave GC collection to the user of the D library?

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Sun May 9 16:57:02 UTC 2021


On Sunday, 9 May 2021 at 16:29:12 UTC, IGotD- wrote:
> I see it as a special case where memory management is bounded 
> to a certain primitive/ways of programming. Also a pool for 
> each possible primitive will increase the meta data.

What do you mean by meta data in this context? I think it should 
resolve at compile time?

Yes, it does imply a programming model if you want GC, but it 
should allow the programmer to write his own scheduler for 
flexibility. You would still need RC between tasks...

> Some in that thread mention that D must head towards RC and 
> that's what my opinion is as well. As Walter do not want to 
> make a special fat pointer type, at least making 
> Phobos/druntime using RC internally would be a step in the 
> right direction.

The problem of not having a fat pointer type is when you have 
arrays of objects. Then you cannot have a RC counter on a 
negative offset, so you will be forced to embed it in all objects 
(whether RC-managed or not).

It can be mitigated by requiring that all owning pointers to 
arrays must be a RC-slice and not a RC-pointer. Then you have a 
RC-slice of static length 1. (shrug)










More information about the Digitalmars-d mailing list