unique ownership + unlimited safe generational references

[Nick Treleaven]

On Sunday, 3 April 2022 at 02:45:45 UTC, Evan Ovadia wrote:
> I'll add some details on improvements made since that original 
> article, which could help explain why this seemingly crazy 
> scheme might work well:

Thanks! (I still need to read these).

>  * If we want to, we can lock an object to prevent it from 
> being freed at runtime, which is a good call in some cases and 
> can let us skip a lot of generation checks:

That's an interesting idea. So for a mutable object shared across 
threads in D, an atomic int could be incremented before 
dereferencing fields. Any intervening call to free the object 
would be deferred by the allocator until after the dereferencing. 
And this should have better cache locality than atomic reference 
counting.

> If D wants to use any of these ideas, just give me a holler! 
> Always happy to discuss.

I'd prefer D supported generational references instead of @live 
which seems to be like rust's unique mutability. Failing that 
perhaps generational references can be supported in a D library, 
but they'd only work with compatible objects.