EXCELLENT!

Posted Jul 12, 2022 19:26 UTC (Tue) by tux3 (subscriber, #101245)
In reply to: EXCELLENT! by khim
Parent article: Rust frontend approved for GCC

But this wouldn't require user-defined move constructors, right?

We don't have to use C++ as a references. You just.. apply relocations to fields tagged 'self lifetime after a move.

Today, the compilers knows moving is a memcpy.
With self-referential types, it would add (dst-src) to some fields after the memcpy, to maintain self-referentialness.

It's not obvious to me where this ought to go wrong.

to post comments

EXCELLENT!

Posted Jul 12, 2022 20:29 UTC (Tue) by atnot (guest, #124910) [Link] (2 responses)

I don't think this is feasible, at least not in the anything but very simple cases. Imagine for example a struct that stores some text in a string type with inline storage optimization and also holds a reference to a substring. This means that depending on the length of the string, which is probably buried deep in some unsafe code, your struct might be self-referential or not.

How do you automatically determine how to move this type? If you could track all of this, you'd be halfway towards a garbage collector.

EXCELLENT!

Posted Jul 14, 2022 9:56 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

> If you could track all of this, you'd be halfway towards a garbage collector.

Half-way toward move constructor, not garbage collector. But yeah, it's pretty hard to stop this madness.

Rust already have support for self-referential structures. You implement them with unsafe and pointers, mark with Unpin and that's it.

I'm not yet convinced that's the problem which happens often enough that complicating safe Rust is worth it.

EXCELLENT!

Posted Jul 14, 2022 11:23 UTC (Thu) by atnot (guest, #124910) [Link]

> Half-way toward move constructor, not garbage collector.

What I was alluding to was that if you could track every pointer and reference to some piece of data for the purpose of modifying them as that data moves, you are just one "if refcount == 0 free" away from garbage collection.

EXCELLENT!

Posted Jul 14, 2022 9:50 UTC (Thu) by khim (subscriber, #9252) [Link]

> But this wouldn't require user-defined move constructors, right?

No, it's the opposite: move constructors would make the whole thing much harder if not impossible.

Because if move is implemented by memcpy then you may consider it atomic: it may fail, but since old piece is still valid before memcpy returns you can easily pretend you never started the process.

With user-defined move constructors you have to deal with half-moved types where both old and new copy are corrupted.

> You just.. apply relocations to fields tagged 'self lifetime after a move.

That's probably doable but you would invariably trigger ire of people who want to create some even more optimized and convoluted data structures.

> It's not obvious to me where this ought to go wrong.

There are just too much complexity. You couldn't just get away with simple self-referential types. Someone would want Option immediately. Then Result. Then derive. Then there would be huge battle with people who would [rightfully] point out that special-casing Option and Result is wrong and you need more general solution.

And eventually you end up with language whose complexity dwarfs C++ and PL/I. Just to support tiny niche corner case which 99% of time is not needed and 99.99% of time can be avoided.

I don't think it's good use of complexity budget. I like the pin solution much better. Yes, it requires use of unsafe. And thus is supposed to be used in 0.01% of time where self-referential structures offer such a compelling benefit that all that complexity is actually justified. That's enough.