Tbh, I would have imagined the SHA-256 transition to work differently.

Let's treat git as a SHA1-keyed object storage. The problem is that we currently use SHA1 both as database key and as hash for integrity validation. At first, I would have only changed the latter.

Local: Request object with key x (SHA1). Remote: Here are the bytes for key x (SHA1) with hash SHA-256. Local: Validate the bytes vs SHA-256.

Local: Store the following bytes with key x (SHA1). Remote: Check if key x has ever been stored in the database. If so check that the SHA-256 of the new bytes matches the SHA-256 stored under key x. The only thing the repo has to keep is a LUT from stored keys (SHA1) to hash (SHA-256). The prevents SHA1 collisions from being stored.

The SHA1 key then just becomes a convenient alias for an object. The only restriction is that you can't have two objects with the same SHA1 in a repo. We already kinda do this when we refer to commits with the first few chars of the SHA1. If there is a "collision" git already detects it and asks you for more characters.

Finally, you can convert the internal representation of the tree to SHA-256. If some legacy client requests aliases via SHA1 you use the LUT, new clients request the SHA256 directly.

Am I missing anything obvious here?

Plenty of high refresh gaming monitors out there that use HDMI 2.1 or DP1.4 with DSC.

DSC is just the "card up the sleeve" for DP1.4, you can push it all the way to 4K 240hz HDR. So there is little incentive to switch to DP2.1 for OEMs.

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.

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.

Niko Matsakis (T-Lang) has since also published a post on only-bounds: https://smallcultfollowing.com/babysteps/blog/2026/06/09/onl.... Sized hierarchy, Move, and Forget/Leak all share the same fundamental compat issues, so we're all pretty motivated to solve the underlying problems in a way that enables all the other features to be built on top.

I had read that post, but IIUC it doesn't address the kind of backcompat issues that I meant to be referring to (the ones that would apply even if there was only ever going to be one new question-mark trait).

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!

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.

Passing ownership to another thread is not the same as forgetting/leaking.

The point of !Forget is ensuring that once the owner goes out of scope the destructor must be guaranteed to run. An infinite loop is not a problem, cause the new thread will never leave its scope. Ref-cycles are a problem, cause you can create a ref-cycle. Then the program flow leaves the scope which will run the drop on all RC's but not the drop on the inner type.

> the point of Pin is to wrap types that CAN move.

I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.

Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place.

Meanwhile, !Move types can't ever move. The object has to remain in the inital place it was constructed in. !Move requires in-place construction and emplacement to be ergonomic at all.

> I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.

You could model this with a state machine enum where the "stay put" phase is a variant that accepts a !Move, like so:

  enum StateMachine {
      InitialState,
      State1(String),
      State2(Box),
      TerminalState,
  }

Stupid question, can't this trivially be solved by having a movable constructor / builder type that then gets turned into a non-movable type when built?

Sure, thats one reason why IntoFuture and Future exist. Imo, in hindsight this is also main mistake in aysnc Rust: The whole async system should be build around IntoFuture rather than Future (async fn should return impl IntoFuture).

That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.

You're right that this is an important issue. I wrote a post explaining this in some detail, so at the very least we avoid having the same problem with generator functions:

https://blog.yoshuawuyts.com/gen-auto-trait-problem

Oh yeah, I've read about all your blog post on this topic :)

To dump some ideas on you: I think one missing piece might be that FnOnce() -> impl Future should implement IntoFuture. Async runtimes would then use IntoFuture in their APIs agressively.

I call this a "workload blueprint" at work. Its a closure/type that contains all the info to start the workload, but in a minimal form. In Rust terms this would be a buildprint that is ideally Send + Move + Forget + 'static, even if the actual work (and the backing struct of the Future) is !Send (e.g. It holds an Rc across await points).

Runtimes could use this for their advantage: There would be a global pool of "workload blueprint" that can be stolen by any executer thread, but once a !Send workload has started on one thread it can't be migrated to another.

This in combination with matklad's ideas about seperating TaskSend from ThreadSend (https://matklad.github.io/2023/12/10/nsfw.html) would solve most of my async pain points.

Thanks for the explanation (though I have to admit I liked your old blog theme more).

Since it's just a matter of how async get desugared, can it be changed through an edition?