4 ms·
While I don't strongly object to Rust's choice here, and I agree that production code should have a type signature on every function, I think this is more a pla
by dllthomas 4y ago
While I don't strongly object to Rust's choice here, and I agree that production code should have a type signature on every function, I think this is more a place for lint/clippy/whatever. There's no need to gate the programmer trying something on them having produced a type signature that could be inferred.
- estebank 4y agoYou might be interested to know that rustc does have some limited ability to infer return types[1], but there are so many edge cases that the feature as it exists today isn't perfect (and won't let you produce a binary). I believe that 1) type alias = impl Trait; will make prototyping easier, and 2) we should allow -> _ in return types in private functions so that they become an allowed part of the language but critically can't become a semver hazard in crates' APIs. [1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=337deb8f418c8af067a38c893319e257 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- tialaramex 4y agoWhere do I sign up to fight you on that last one? :D Allowing _ in return position only for private functions feels like something that ends up surprising 99% of people either that this works, or that it doesn't work for their public function and neither group of people are filled with joy as a result. It's not a hill I'd die on, but it would go on my list of things I don't like in Rust, along with most as casts, impl AddAssign for String, is_ascii_predicates(/* taking */ &self)
- estebank 4y agoThe likelihood of it actually landing is quite low, because I suspect quite a few people would agree with you, and as long as rustfix can deal with it I also don't care as strongly about it ^_^