my bad - updated the original node with the code that actually causes the warning.

There's nothing in your update that generates a warning either.

use strict;
use warnings;

BEGIN { package My::Guard; sub new {} }

{
   my $sth;
   my $guard1 = My::Guard->new(sub { $sth->finish });
   my $guard2 = My::Guard->new(sub { $guard1; });
}
[download]

>perl script.pl

>
[download]

By the way, My::Guard already exists as ReleaseAction, Object::Destroyer, AtExit, Scope::Guard, Sub::ScopeFinalizer, etc.

C:\>perl -we"{my $pop;}"

C:\>perl -we"{my $pop;$pop;}"
seless use of private variable in void context at -e line 1.

C:\>perl -Mdiagnostics -we"{my $pop;$pop;}"
Useless use of private variable in void context at -e line 1 (#1)
   (W void) You did something without a side effect in a context that 
+does
   nothing with the return value, such as a statement that doesn't ret
+urn a
   value from a block, or the left side of a scalar comma operator.  V
+ery
   often this points not to stupidity on your part, but a failure of P
+erl
   to parse your program the way you thought it would.  For example, y
+ou'd
   get this if you mixed up your C precedence with Python precedence a
+nd
   said

       $one, $two = 1, 2;

   when you meant to say

       ($one, $two) = (1, 2);

   Another common error is to use ordinary parentheses to construct a 
+list
   reference when you should be using square or curly brackets, for
   example, if you say

       $array = (1,2);

   when you should have said

       $array = [1,2];

   The square brackets explicitly turn a list value into a scalar valu
+e,
   while parentheses do not.  So when a parenthesized list is evaluate
+d in
   a scalar context, the comma is treated like C's comma operator, whi
+ch
   throws away the left argument, which is not what you want.  See
   perlref for more on this.

   This warning will not be issued for numerical constants equal to 0 
+or 1
   since they are often used in statements like

       1 while sub_with_side_effects() ;

   String constants that would normally evaluate to 0 or 1 are warned
   about.


C:\>
[download]

Thanks - I hadn't looked at the diagnostics output.

So really the problem is in the assumption that there is no side effect, wheras in fact there is. The side effect is that the variable is made present in a a new scope which prevents the object from being destroyed (and the destructor has side effects).

Hm, or does it. Since I'm not assigning it to a variable the refcount won't be being increased. But surely it can't be destroyed while it's still in scope - in a void context or not...

I'll test it out and report back.

Since posting this message I have lost about 100xp! Strangely, the node itself is only -1, so I guess someone is upset/annoyed and going on a bit of a seek and destroy mission.

Who said XP doesn't encourage good question writing - I won't be making this mistake again ;)