Precedence on methodcall-assign: $foo .= bar.baz doesn't do what most people expect

[lizmat]

The method call-assign syntax is very nice, and widely used in the ecosystem:

https://gist.github.com/lizmat/9b2495d0d5e8fbc59a79e11ca153deb9

However, over the years many issues have been made about the apparent malfunctioning of .= bar.baz, of which #5803 is the most recent.

The problem is really that when one write $foo .= bar.baz, one is in fact writing ($foo .= bar).baz. The normal cause of action in case of precedence issues, is to add parentheses to indicate the precedence wanted. However, that is NOT possible with the methodcall-assign syntax. $foo .= (bar.baz) will be interpreted as calling the baz method of the result of the call on the bar subroutine.

However, the $foo .= bar.baz syntax is executed without any issues as ($foo .= bar).baz, which just silently drops the result of the .baz method call.

So it feels like we should do one or more of these actions:

• document this specific behaviour of .= better (as it's different from other op= metaops)
• allow the $foo .= (bar.baz) to actually interpret bar as a method call on $foo, instead of a sub call
• drop the precedence of .=, so that $foo .= bar.baz DWIM

[patrickbkr]

I fully support this (one of the many issues about this in the past is by me).

I disagree with the second point though:

• allow the $foo .= (bar.baz) to actually interpret bar as a method call on $foo, instead of a sub call

Syntactically I'd assume that code to fail. It reads like it's calling a bar sub, then calling the baz method on the result and then interpreting the result as a method that's called on $foo!?

This piece of code is dubious at best. I would not want to tack on another special case to the language to give this piece of code a different meaning. Maybe a compile time error is the best course of action here.