update: after tobyinks 3rd update I see that order of operations plays a role, I still think you should perlbug it, because at least the perlop, and warnings, need to warn more about this ...

Documenting Auto-increment and Auto-decrement is great, but needs to warn about MORE, like this case, or  foo($1,$2)  <c>foo("$1","$2")

Even B::Lint doesn't warn about it

B::Concise shows no difference between the two

Even the mighty perlcritic doesn't warn about undefined behaviour

But I actually knew about this and forgot

• unexpected: inside sub($1,$2) if do // then arguments will be changed
• The behavior is [sic] undefined
• Quantum Weirdness and the Increment Operator
• The Universe of Discourse: Undefined behavior in Perl and other languages
• Order of operations, mutators, aliasing and whammies
• order of operations with conditionals at the end

warnings/lint/critic need to recognize and warn me cause I'll probably forget :)

It ought to be easy to recognize an unquoted $1 as a function argument and issue a warning , at least for perlcritic -- if that concise output is any indication, lint might be slightly harder

Maybe perltrap/Common Perl Pitfalls could also use some updating

This part below written before your butterjunkeffect update, on the approach to solving this problem

Ick :) Um, do you really want to find the cause, or do you want a better way to write it?

I'm not inclined to try debugging a program that hacks a tree as a string, I'm inclined to create a tree first (say an array of array or Tree ) and then navigate (calculate distance)

update: tobyink is probably right as to cause

Those rosalind newick trees could be drawn with ascii Dumping trees to a console.

"It ought to be easy to recognize an unquoted $1 as a function argument and issue a warning"

The problem occurs in:

return $1 + sub_that_does_regex_capturing(...);
[download]

$1 is not a function argument in that. $1 hasn't been a function argument in any of the examples in this thread.

The problem is writing an expression where one of the operands has a side-effect that can alter the value of another operand. This is very hard to detect through static analysis of source code; it's probably not especially easy to detect at run-time either. Heuristics may be able to catch some common cases.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Interesting. This gave me the idea of trying this code:

$_ = 1; print $_ + $_++;

Amazingly enough, this prints 3, not 2

But this does print 2:

$_ = 1; print 0+$_ + $_++;

The problem occurs in... This is very hard to detect through static analysis of source code; it's probably not especially easy to detect at run-time either.

Yes, I recognized that, but since PPI certainly detects  $1 and s/// as $1 and substitution operator, I see no reason perlcritic couldn't do the same, it uses PPI

I also recognize the abilities of warnings/lint, they actually run the code and can detect this case as well -- sure it might be too much to ask from warnings (could be slow) , but its not too much to ask of lint :)