So basically, allow us to replace the following:
this answer 42
This is particularly expressive when the right-hand operand is more complicated:
answer 12 * 3 - (8 - 14) * 2
There’s also the case where the call isn’t the root of the expression:
val x = capture 3 + 4 bar(release x)
This is especially nice as you can modify an existing statement by dropping in your method name and not worrying about the trailing parenthesis of an equivalent non-infix method call (which doesn’t necessarily improve legibility anyway, like in these cases, imo.)
One counter-argument would be that the following is confusing if implemented consistently:
answer 38 plus 4
I would propose to special case the precedence here and always evaluate the infix call after the right-hand operand is evaluated. Yes, it would be one more thing to learn when learning Kotlin, but it’s a pretty small tradeoff in this case imo, and would allow for more expressive DSLs.
Another problem is that, while I would really enjoy the syntax for the non-root case, it does seem more prone to misuse:
val x = capture 3 + capture 4 val x = capture 3 plus capture 4 // How would these even parse? Could it be done as we might intend?
Parsing aside, any feature can be misused, so I suppose the question is more about the likelihood of it happening, and understandability to newcomers. Perhaps it could only be allowed in the cases where it’s totally unambiguous, such as the right side of the an assignment statement or as a method parameter.
Thoughts? I’m sure I haven’t considered everything here. Perhaps there would be better way of achieving this in the language without touching infix methods? Allowing on methods more generally sounds pretty extreme, whereas a new “prefix” method qualifier might be clearer, while disallowing calls on existing infix methods in an unintended way.