I see where you're coming from, and I would be unlikely to use them much, but I can see the appeal of closure-like items. The inference would only work for the return type, at least on what I was envisioning.
Conversation
I find myself annotating closures with an explicit return type quite often.. not sure about this idea (but always love to be wrong)
1
6
Because of inference needing it or documentation? Do you write them from the beginning or after you get things working?
2
2
I personally don't feel the need for this feature, but I also know a lot of people that get turned off by Rust due to how ceremonial it can be during development. Some stay around for the benefits, others bounce.
1
1
I want to give people the option to do what they want, and lint against things we know are not best practices. But if you want to rely on spooky action at a distance within code that your consumers won't interact with or just use it during development? Go ahead!
1
2
I'm not sure if I consider closures "action at distance" - my model of this is "can a change in module A that doesn't modify the function signature break module B".
2
4
I'm a pretty verbose coder, so I think I would still type them out everywhere. I think I would prefer less type inference complexity here. (but I'm also very biased there)
1
1
Personally, I would like Rust to be slightly more aggressive with lifetime inference, but not with any other type inference
1
I agree on that (although, now that you mention it, I am annoyed that Rust elides `StructWithLifetime<'_>` to `StructWithLifetime`, because that may hide lifetimes in the return position. I like that Rust has the differentiation between things with references inside...
2
1
Agreed! You might already be aware of this, but I think you can enforce writing the `'_` explicitly with the `#![warn(rust_2018_idioms)]` lint.