upvote

points

by melodyogonna12 hours ago |
comments
upvoteby virtualritz11 hours ago|
next
[-]
But Rust has editions.

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

reply
upvoteby yccs279 hours ago|
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.
reply
upvoteby simonask8 hours ago|
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.

reply
upvoteby Dagonfly7 hours ago|
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.

reply
upvoteby ameliaquining4 hours ago|
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.
reply
upvoteby simonask6 hours ago|
parent|
prev|
[-]
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!

reply
upvoteby Dagonfly6 hours ago|
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.

reply
upvoteby dubi_steinkek9 hours ago|
prev|
[-]
Which stdlib collections and types should become `!Move`?
reply
upvoteby simonask8 hours ago|
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.

reply
upvoteby ameliaquining4 hours ago|
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.
reply