IIRC, this also works:

$gold if 0;
[download]

It doesn't modify the var. It doesn't result in any run-time code at all.

Demo:

$ perl -Mv5.10 -we \
'do { my $x = 42; sub {          say eval q{$x} } }->()'
Variable "$x" is not available at (eval 1) line 1.
Use of uninitialized value in say at -e line 1.


$ perl -Mv5.10 -we \
'do { my $x = 42; sub { $x if 0; say eval q{$x} } }->()'
42
[download]

Update: Tested and added demo.

That's kinda cool if it works (can't test ATM)

But this relies on constant folding happening after the PAD was populated.

I'd feel uncomfortable to use an undocumented feature and risk to run into problems in later perl versions.

IIRC they started to deprecate the similar my $var if 0; (poor man's state ) so I'm kind of sceptical that's guaranteed to stay.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

But this relies on constant folding happening after the PAD was populated.

That's pretty much necessary. But let's imagine it's not.

Anything that can be optimized away would run into that problem. It's hard to write a version that doesn't warn and can't be optimized away. For example, look at the following:

my $false = 0;  # Perhaps a global.

capture( $gold ) if $false;  # `capture` doesn't need to exist.
[download]

Even that could be optimized away. And that's far from readable.

Since the symbol table is externally modifiable, the following can't be optimized away and provides a solution:

sub capture { }

capture( $gold );
[download]

It does comes at a performance cost. You could, of course, use an opcode checker to optimize the call away. But then we're back to the beginning.

Actually, not really. An opcode checker manipulates ops, so that means the padop for $gold must have been created already. So that might be a very simple module that makes the intent clear.