I have a parser combinator library, and as part of the design of that library, I had to decide whether to use Fn or FnMut for the closure types. It's a trade-off between convenient to use variable capturing and inability to parse in multiple threads, or allow parsing in multiple threads, but variable capture needs everything wrapped in Arc and friends.
It would be nice if I didn't have to make this tradeoff, and a proposal like this on the surface appears to be trying to solve a problem like that, but then the only motivation presented is to make it trivial to write getters/setters? There are much better ways to trivialize getters (e.g., 'properties') if that were a desirable goal (which I would argue is not.)
But I can't even make sense of the following:
inouttypes are only allowed in methods, and their mutability must be the same as theselfargument.
If you can only mutate with &mut self, and you can only share with &self, what can you do with &inout? It doesn't seem to do anything except be a syntactical inference about a question with only one (obvious) answer in the first place?
And I have to second the point that just removing _mut is not an improvement. In addition to the fact that it is inherently helpful, you'd be asking all Rust programmers to adapt to the fact that they'd have to reinterpret all previously existing code to account for the presence of a new API design possibility. Which while not being a breaking change, is still a burden to place on people.
(Addendum: I hope people will take the time to understand this last point, because language stability is not just about semver compatibility. It's also about not burdening developers to have to make new decisions when looking at old code, and it's one of the reasons that new syntax options need strong motivations; having new ways to do old things forces everyone to ask whether the old way or new way is correct for code that is largely 'finished'. It creates churn and debate about things that previously didn't require it, which makes people feel as though they should be waiting for the language to mature even when it is already serviceable.)