July 13
On Saturday, 12 July 2025 at 23:32:59 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Mutability in language doesn't matter for this kind of thing.
>
> For internal details like this you can break const, immutable and shared, they are a preventative measure for the human, not for the runtime.

But having an "need to be mutable RC" in an object makes it impossible for the compiler to store it e.g. in read-only memory.

> What matters is if something is in read only memory

Of course this is what I meant. If an Object is stored in memory that's e.g. protected by an MPU, the RC need to be stored in a different place.

And if storing in a different place is once implemented, why don't use it always? This makes management much easier.
July 14

On Saturday, 12 July 2025 at 21:36:18 UTC, Dukc wrote:

>

On Friday, 11 July 2025 at 20:18:59 UTC, Richard (Rikki) Andrew Cattermole wrote:

>

As a topic supporting ARC style memory management has long since been discussed. This isn't a new idea.

For ARC at the language level to exist, it requires that all memory in D would have to have a predictable state access. For example with a slice, not only do you need a pointer, length, but also the state object.

Well not quite.

The reference count for ARC allocations would presumably exist in the runtime registry, not in the allocated object itself. Just like runtime type information does for garbage collected allocations.

Storing the ref count along the object would likely perform better, but don't think it would be done like that in D because the same reference types are used to deal with objects allocated in C.

RTTI doesn’t exist in the runtime per-say. That is generated by the compiler for every type at compile time and the first entry of the vtable of a class stores a reference to the RTTI.

I think RTTI TypeInfo and ModuleInfo classes are the only real classes in D that are const/read-only instantiated?

1 2
Next ›   Last »