I agree with this. But I still don’t understand how this goal meshes well with the
_1 syntax of partial application. It is my understanding that one can have either informative (longer) variable names, or the partial application syntax (for those variables), but not both at the same time. If I misunderstand, please clarify.
You are right. I would frame it differently then: for the very simple cases which are most commonly used (closures with one or two arguments), the cost is small. For more complex cases, a the partial application syntax saves more keystrokes, but runs into other issues of complex/unclear semantics (as demonstrated by the discussion of #24990 and the related PRs/issues).
Just to clarify: I was initially very enthusiastic about partial application syntax because think it would save quite a bit of typing. Then having carefully read all of the above discussions, I now think that all the proposed rules have to be quite complex because of various corner cases.
It is possible to come up with well-defined semantics for these, but it would mean that I would need to remember some nontrivial rules about the
_ syntax. This would make me treat it like precedence: I know that the rules exist, I know that they are well-defined, but I still don’t rely on all them since I would have to keep looking them up. So I would probably limit myself to the simple cases (like
_ + y), in which case a closure is not that much of a bother.