It's also not an all or nothing rule: `type Alias = impl Trait;` will have in effect the same issues that return and argument type inference could have, and I a

It's also not an all or nothing rule: `type Alias = impl Trait;` will have in effect the same issues that return and argument type inference could have, and I am convinced that the issues around diagnostics caused by type errors involving it can be made almost as clear as E0308 is already today. I also believe that Rust can afford to have type inference in functions, but only for crate-local functions, I wouldn't ever want to see a `pub fn foo(x: _) -> _ {}` be allowed. Your type signatures are a contract. You can have a "gentleman's agreement" within your own project, but you want a signed and notarized contract with everyone else :) An interesting thing is that for return types all you need is evaluating the body (which is why rustc already suggests the right type when writing `-> _`, it was super-easy to implement), while parameter type inference requires global inference (which requires a full-blown change to the type checker's implementation, not as worth it for a "mere suggestion").