Migrating an existing more modern GC to D's gc.d

[David Bennett]

On Tuesday, 10 April 2018 at 08:10:32 UTC, Jonathan M Davis wrote:
>
> Yes. They expect it to work, and as the language is currently 
> designed, it works perfectly well. In fact, it's even built 
> into the language. e.g.
>
>     int[] foo() pure
>     {
>         return [1, 2, 3, 4];
>     }
>
>     void main()
>     {
>         immutable arr = foo();
>     }
>
> compiles thanks to the fact that the compiler can guarantee 
> from the signature of foo that its return value is unique.
>

Oh is that run at runtime? I thought D was just smart and did it 
using CTFE.

>
> We also have std.exception.assumeUnique (which is just a cast 
> to immutable) as a way to document that you're guaranteeing 
> that a reference to an object is unique and therefore can be 
> safely cast to immutable.
>

Can't say I've used std.exception.assumeUnique, but I guess other 
people have a use for it as it exists.

Would be nice if you could inject type checking information at 
compile time without effecting the storage class. But thats a bit 
OT now.

>
> Because of how restrictive shared and immutable are, you 
> frequently have to build them from thread-local, mutable data. 
> And while it's preferable to have as little in your program be 
> shared as possible and to favor solutions such as doing message 
> passing with std.concurrency, there are situations where you 
> pretty much need to have complex shared objects. And since D is 
> a systems language, we're a lot more restricted in the 
> assumptions that we can make in comparison to a language such 
> as Java or C#.
>

Yeah i agree that any solution should keep in mind that D is a 
systems language and should allow you to do stuff when you need 
to.

Oh, I just had a much simpler idea that shouldn't have any 
issues, I'll see if that makes the GC faster to allocate. 
(everything else is the same)