Hacker News new | past | comments | ask | show | jobs | submit
melodyogonna | on: Rust project goals: Immobile types and guaranteed destructors
Linear types requires significant work to incorporate into the core built-in collections and types. I've been following the work on Mojo to enable Linear type support for built-in types and collections, I don't think Rust's language semantics will allow for the same level of integration (Rust is already stable).
virtualritz | parent | next
But Rust has editions.

That is a big lever language designers can use if they painted themselves into a corner.

yccs27 | root | parent
Yes, editions are a great mechanism. It still has its limits, especially if you want easy edition migrations. All existing Rust code assumes it can drop any type whenever it wants, and that is not something you can just change across editions. You have to be very careful with defaults if you don't want conflicts when crossing edition boundaries.
simonask | root | parent
The naïve idea would be to just say that all generic parameters have an implicit `where T: Move` bound, and you have to explicitly opt out of it with `where T: ?Move`, just like with `?Sized`.

In fact, that's exactly how I would expect it to work, but there may be non-obvious drawbacks.

Dagonfly | root | parent
The compat issue has always been associated types on std traits.

For example, should Iterator::Item be Move or ?Move

If you leave it as Move, you can't create any iterators over !Move types. If you change it to ?Move, then functions using generic iterators can't assume that the elements of an Iterator are always moveable. Which is a breaking change compared to now.

The most critical trait is probably Deref. Using !Move types without `Deref::Target: ?Move` is painful, because calling any method on boxed types relies on Deref.

ameliaquining | root | parent | next
The people working on this are aware that it poses backcompat problems that don't have obvious solutions. They are looking into non-obvious solutions. https://lcnr.de/blog/2025/11/28/implicit-auto-traits-assoc-t... is the most up-to-date one I'm currently aware of.
simonask | root | parent
I'm very probably missing something, but as a user I would definitely expect `Iterator::Item: Move`, but then also that `&{mut} T: Move where T: ?Move`.

But yeah I can see how these bounds are somewhat viral. Thanks!

Dagonfly | root | parent
Here is an example of the problem: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Imagine if MyTrait comes from core/std. Adding an opt-out bound like ?Sized (or ?Move) is a breaking change for any generic code that relies on Sized/Move. But you want some traits from std to be open for !Move types.

dubi_steinkek | parent
Which stdlib collections and types should become `!Move`?
simonask | root | parent
None. The question is more what happens when you put a `!Move` type into, say, `Vec<T>`, because that's a collection type that regularly moves its elements to a new allocation when it grows or shrinks.

Should it be possible to construct a `Vec<T>` whose size can never change? Is there a subset of Vec's API that can be annotated with `where T: ?Move`? These are all important design questions, with the potential to break 99% of existing Rust code.

ameliaquining | root | parent
We already have a Vec<T> whose size can't change, it is called Box<[T]>. So Vec doesn't need to support !Move types.