> I think this interpretation is right: there is a clear "easy answer" here. But it is unsatisfying.
It seems like that actually mostly solves the problem though? Syntactically, there are four relationships a type parameter can have to a trait:
<T> // dunno
<T: Leak> // needs leak
<T: !Leak> // needs not leak
<T: ?Leak> // don't care about leak
But `<T>` isn't actually a semantic possibility; it effectively gets desugared to `<T: ?Leak>` ("don't care") unless Leak is a ?Trait.
> The problem is that as a consequence, any 2024-edition trait that doesn't have Leak bounds on the generics in its functions cannot be implemented in 2021-edition code
In "edition 2021" `<T>` desugars to `<T: Leak>`, which is not "don't care about leak". But 2021 code can still use `<T: ?Leak>` to explicitly not care about leak, just like it can use `<T: ?Sized>` to explicitly not care about size. (So 2021-edition code can implement 2024-edition traits that don't have Leak bounds, it just has to write the lack-of-Leak-bound explicitly.)
In "edition 2024" `<T>` desugars to `<T: ?Leak>`, (and `<T: ?Send>`, and `<T: ?RandomOtherTrait>`, etc, but that's not a change). (2024 code can still explicitly declare `<T: Leak>` if it wants, as noted.)
So in the desugaring interpretation, the only thing you've changed is the default trait bound; all the semantics are still there. 2021 keeps the conservative, backward-compatible convention, which can't actually use !Leak types very much due to running into traits like Iterator or Deref, but can (explicitly) support !Leak types in most generic interfaces. Meanwhile, 2024 uses the actually-useful convention, and can opt-in to `<T: ?Leak>` versions of Iterator et al piecemeal, with the `<T: Leak>` versions being automatically derivable.
I always enjoy posts by boats because I feel like they can make me understand almost all of it, even without me understanding the intricacies of type discussions.
Off topic and I'm obviously not the target audience, but based on the headline and the domain name, I was not expecting a discussion around the Rust language!
It seems like that actually mostly solves the problem though? Syntactically, there are four relationships a type parameter can have to a trait:
But `<T>` isn't actually a semantic possibility; it effectively gets desugared to `<T: ?Leak>` ("don't care") unless Leak is a ?Trait.> The problem is that as a consequence, any 2024-edition trait that doesn't have Leak bounds on the generics in its functions cannot be implemented in 2021-edition code
In "edition 2021" `<T>` desugars to `<T: Leak>`, which is not "don't care about leak". But 2021 code can still use `<T: ?Leak>` to explicitly not care about leak, just like it can use `<T: ?Sized>` to explicitly not care about size. (So 2021-edition code can implement 2024-edition traits that don't have Leak bounds, it just has to write the lack-of-Leak-bound explicitly.)
In "edition 2024" `<T>` desugars to `<T: ?Leak>`, (and `<T: ?Send>`, and `<T: ?RandomOtherTrait>`, etc, but that's not a change). (2024 code can still explicitly declare `<T: Leak>` if it wants, as noted.)
So in the desugaring interpretation, the only thing you've changed is the default trait bound; all the semantics are still there. 2021 keeps the conservative, backward-compatible convention, which can't actually use !Leak types very much due to running into traits like Iterator or Deref, but can (explicitly) support !Leak types in most generic interfaces. Meanwhile, 2024 uses the actually-useful convention, and can opt-in to `<T: ?Leak>` versions of Iterator et al piecemeal, with the `<T: Leak>` versions being automatically derivable.