That's what my post is suggesting. The tricky part is making sure you don't sneak a !Leak type from 2024 code into some 2021 code.

If you inserted `+ Leak` on every trait bound in 2021 code at parsing time, then I don't think you'd need any extra firewall later.

You'd just treat all code the same, as supporting Leak, and process trait bounds as usual.

Ariel Ben-Yehuda has sent me an example which shows how much harder it is than that, and which this wouldn't cover. I'm going to write a follow up blog post.

EDIT: https://without.boats/blog/follow-up-to-changing-the-rules-o...

With the solution I imagine, this example wouldn't compile. In the crate bar, edition 2021, the code written as:

    fn foo<T>(input: T)

would actually parse as if:

    fn foo<T: Leak>(input: T)

An implicit Leak bound would be inserted into AST of every trait bound in the 2021 edition. Then all code from all editions would be interpreted the same.

This way, the 2021 code wouldn't compile, because the 2024 trait requires `<T>` bound, and the 2021 code can only express `<T: Leak>` and nothing less.

2021 code could not work at all with any 2024 code that allows !Leak. libstd would have to add `+ Leak` to all existing APIs. Upgrading to 2024 edition would need a migration to change the bounds.

With what I described, bar would not compile, because the compiler would add a "+ Leak" bound to T.

The unfortunate part is that means that upgrading foo to the 2024 edition means you either have to break backwards compatibility (at least for 2021 code) or add Leak bounds to type parameters and trait objects. There could be a cargo fix rule to do that update for you.

It is really unfortunate that existing APIs can't be made more general without breaking compatibility though.

A bit late, but see also https://news.ycombinator.com/item?id=37588046 (which at least seems to cover that and most of the other issues mentioned).