Hook when address of object is changed

@RustyYato @kornel
Okay, if custom move semantic can introduce a safety issue than maybe Rust should introduce feature for Garbage Collectors (basic and custom) ?

Rust could generate code for types that impl some trait (but not provide API to this code) that track unique location of each object and update the table to them and user the data structure where Rust should put unique address and then code in background can collect the not reachable objects by different strategies ...

Actually, Rust even should generate code only for objects that locates on stack and only if they impl trait, for example trait GcObject or trait Root

In such way we can guarantee safety and high performance of addon as Garbage Collector

Rust is explicitly targeting a niche of languages without a GC, so any GC support is extremely unlikely. Especially, if it could create doubt about how much of the language works without the GC. For example, the D language failed to get traction in Rust's niche, because users worry that having an optional GC makes no-GC case a second-class citizen in the ecosystem.

So let's take a step back: why do you want to track address changes? What does it enable?

5 Likes

Yes, I'm curious. What is this for?

To my simple mind if an object is being moved in memory, thanks to a reallocation, then it is currently owned/mutably borrowed by the thing triggering the reallocation.

If some other code then needs to be notified of that move that implies it also has an alias/pointer referencing that same object.

Doesn't that break every rule in the book?

No, I do not think so ...

It is possible to add code generation like with examples with future and all other things leave to external crate ... I mean no GC in libstd but it will be provided by external crate and in such case GC does not make non-GC Rust a second-class citizen ... it just make it optional for people that come from other languages !!

The developer will decide if it wants high performance it should not use GC, but if it is just student or maybe person that try some scratch some code quickly it will help them a lot !!

That statement worries me.

Excuse my language/compiler naivety but as I understands GC requires some kind of run time to do that garbage collection activity. Further it requires the language/compiler to generate code that will cause garbage collection to happen when all references to an object are gone.

With all that mechanism conceivably one could write code that relies on GC. Code that looks like Java, Javascript, Python, whatever.

Likely crates would get written in that style that require applications to include that run-time and likely that applications get written in the GC "dialect" of Rust.

Soon there will be layers of crates depending on crates, depending on crates... that depend on GC. The result being applications that use all that. And applications that do not and cannot.

That would be a major split in the Rust user base. Those that use Rust and those that use Rust-gc.

The chaos would be even worse than the threaded vs async worlds we have in Rust today.

Perhaps not so easy. If developer want to use the functionality provided by a crate that depends on GC then the developer is forced to go down that path or forgo that functionality. We already see this coercion with crates that use async.

It should also be explicitly mentioned that so far, every single use case for move constructors / move "hooks" / any way of running arbitrary user-defined code on moves has turned out on closer scrutiny to either not actually be solved by that feature at all (e.g. making safe self-referential types requires way more than this), or to have a far more lightweight solution (like Pin). This is probably one of the top 5 ideas that people constantly repropose for Rust every few weeks, and every single time it's revealed to be an XY problem.

If you want this discussion to go anywhere useful, you have to talk about your use case and the real problem you ran into implementing it, not about what you've convinced yourself the solution is.

6 Likes

But it is already possible to use GC:

But with bad performance due to double pointers ...
One pointer for internal use (due that object in Rust can be moved) and second pointer to actual resource

ferris maybe great and all but I'm pretty sure that is not what we have in mind when we talk of Rust, the language, supporting GC itself.

You're assuming that GC would make Rust easier, but that is not true. All existing code, crates, and the standard library are without GC support. A "GC-Rust" user would still need to learn how to use ownership and borrowing, and then learn how it interacts with a GC — that's more to learn, not less.

GC can't automatically be enabled in existing Rust code. Ownership and borrowing are not only used for memory management, but also for resource management and safe concurrency. It's not sufficient to add GC to relax ownership and borrowing — the code could break in lots of horrible ways.

Adding support for a GC in the standard library and 3rd party crates would split the ecosystem into with-GC and no-GC parts. Such split would be a burden for users and crate authors, and from D's experience we know it's a grave danger for a language.

Rust is successful in its niche, because it has no GC. If you can use a GC, and you need a language for some quick scratch code, there are plenty of more suitable languages.

4 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.