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!
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:
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:
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.
It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:
fn foo(namedParam internalName: bool) { // use internalName here }
fn foo(unnamedParam: bool)
> Consequently, in the case of portable batteries included in products covered by Regulation (EU) 2023/1670, the removability and replaceability obligations set out in Annex II of that Regulation prevail over those set out in Regulation (EU) 2023/1542.
The ecodesign law (spare part but 1000 cycle exemption) pevails over the batteries law.
Negative prices have no effect on grid stability. It just means that the day-ahead market was cleared below 0, i.e. for every consumer (buyer) there is a producer (seller) selling at this price. The market is still balanced with consumption==production.
Now, you can ask the question: Why are so many producers willing to sell below 0? That has to do with misplaced incentives. For older or home-installed renewables there is a feed-in tarrif which guarantees a fixed revenue at all times. So there is an incentive to sell even for negative market prices. Newer installations can't opt for the guaranteed revenue model with revenue during negative prices any more.
Redispatch follows afterwards, if the market result clashes with physics: The physical grid can't transport the power from producer to consumer. There was no unusual amount of redispatch during easter.
> It just means that the day-ahead market was cleared below 0
No, it doesn't. The article is explicitly about intraday-prices. So day-ahead clearance made invalid assumptions about generations and consumption that were not met during the day. This kind of miscalculation does require additional (costly) redispatch measures to mitigate the overproduction, and it can affect grid stability.
You are right that intraday went even more negative than day-ahead. But I disagree about the rest of your comment. A spread between day-ahead and intraday does not imply additional redispatch. Only some of it might have been countertrading by the grid operators.
> This is currently being defined and is almost complete.
>> no signed stamp of approval from on high
> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
Unclear how this quoted comment relates to what I was replying to (which was about exporting / backing up your credentials).
But I'll respond.
> Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID.
AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.
Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.
At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.
For DP adoption it's too late. They should push for USB4 / Thunderbolt 4 instead. We are in the phase where about every new laptop has USB4. Connecting your laptop/phone to a TV might be a selling point. I'd love that for hotel TVs.
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.