I could be wrong about this, but given the constrains the Rust language is under (in this case specifically making the semantics of a given piece of code obvious in a local context), I'd say that the current closure syntax is either some kind of (local) optimum, or quite close to it.
The various suggestions I've seen here suffer from various issues:
- Syntax unsupported by the parser. It could be added but then the issue becomes that we might as well stick with the current syntax
-
_-based syntax suffers from ambiguous scoping rules, and using them in macros would be a potent recipe for bugs i.e. those 2 language features would not compose well. - None of these options I've seen is all that much shorter than the current closure syntax. Combined with the previous issues it raises the question of whether it's worth spending engineering effort on when something like GATs, full const generics (or, dare to dream, full-blown dependent typing) or other language-based features would yield a much better ROI. This matters because even though volunteers are joining the Rust community, especially the resources available to the language team is still quite limited from what I can see. And this makes sense, working on the language part of Rust isn't exactly low-hanging fruit and requires quite a bit of expertise.