Compatibility:
Since T declaration is implicit and can't be used inside fn this change doesn't break anything.
Motivation:
This change allows passing &dyn and &mut dyn directly to such methods. T becomes dyn Trait, &T becomes &dyn Trait - though T has dynamic size the parameter &T is a fixed size type so everything is fine.
Hm, you are right. And if such method is declared in trait the compiler can't even check the code for such things and remove ?Sized. May be this improvement can be put behind the next "language version".
Changing the default would just make the other case "not readable:"
fn foo(x: &(impl Sized + Trait)) {
bar(x)
}
fn bar<T: Trait>(x: &T) {}
// Or perhaps even this, for consistency:
fn bar<T: Sized + Trait>(x: &T) {}
The choice was made based on which case is more common. Having a weird "unreadable" syntax for an uncommon case is better than that case not being possible at all, and it's certainly better than having the common case be "unreadable."