4 ms·

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. E

• pornel 3y ago
  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.
• thayne 3y ago
  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.
• a1369209993 3y ago
  A bit late, but see also https://news.ycombinator.com/item?id=37588046 https://news.ycombinator.com/item?id=37588046 (which at least seems to cover that and most of the other issues mentioned).