I don't see why one should assume that "watch for the value of a particular variable to change" should include "and it might change because a whole different variable comes into existence because you called the function again".

Feel free to implement your own semantics for "watch". This took me a whole few minutes, including testing it. But when I implement semantics for "watch a variable", I actually want to watch a variable, not "watch whichever instance of a whole class of related variables is currently in scope, if any".

Another benefit with my approach is that I get notified of changes that happen to the value of the watched variable even when it isn't currently in scope under the same name. That's actually the type of thing that makes "what the heck is changing $x?!" tricky to find which might actually motivate me to want a debugger's "watch" feature. *shrug*

OK that clarifies your approach, thx!

But should be noted that references are often reused after a variable was destroyed (like when exiting scope)

So a watch might trigger for something completely unrelated...

Cheers Rolf

( addicted to the Perl Programming Language)

But should be noted that references are often reused after a variable was destroyed (like when exiting scope)

The address of a reference might get re-used. References don't get re-used. Either you didn't weaken the reference and so the referenced item doesn't get destroyed. Or you do weaken the reference and, when the referenced item gets destroyed, the weakened reference is set to 0 (so any re-use of that particular address doesn't matter to your reference).

- tye