It doesn't matter whether the value changes; it only matters whether the variable was written to.

I'm gonna regret persisting, but why?

I'm not trying to be obnoxious, the answer to that question would really determine the appropriate solution. I'm not fond of pat answers, but this really does seem to be a case of the 'XY problem' tag that was all rage around here a month or so ago.

You say the value of $x doesn't matter, only whether it is written to but

• In your example, unless += is being overloaded, $x will always be "written to" if @kabluther contains anything--even if the value added is 0.

  In which case, knowing whether $x 'was written to', is equivalent to knowing 'if @kabluther was non-empty'.

• If += is overloaded, then you're already paying the penalty of overloading and adding a flag internally to the overload method and a second method to query the flag will add negligable extra overhead.

Ultimately, you already mentioned the 'obvious' solution when you mentioned tie. You mention efficiency fears, which can be well-founded, but if you really need the functionality, then whether the test is hidden behind a tie, or whether you assigned the return from the methods to a local value, tested it, set a flag and then conditionally added it to $x, the overhead is pretty much going to be the same.

One possibility is that you fear tying $x to achieve this particular piece of functionality because of the performance affect it will have upon the use of $x throughout the rest of the program?

In which case, use tied lexical variable local to the sub and assign/add is final value to $x when the loop is complete--if it has 'been written to'. That would avoid any penalty of tying $x in the wider scope.

However, if you continue to use += on the tied variable, the STORE method will always be called as mentioned above, so you still won't know whether the there is any contribution from the return value of the methods called or not.

Definitely an XY problem.