Challenge 3: Demonstrate @_ Aliasing — Possible Solution
====================================================================

use strict;
use warnings;
use feature 'say';

# --- unsafe version: modifies the caller's variable ---
sub reset_to_zero {
    $_[0] = 0;
}

my $x = 99;
reset_to_zero($x);
say $x;   # 0 — changed, even though $x was never explicitly passed "by reference"

# --- safe version: unpacks first, caller's variable is untouched ---
sub reset_to_zero_safe {
    my ($n) = @_;
    $n = 0;
}

my $y = 99;
reset_to_zero_safe($y);
say $y;   # 99 — unchanged

Output:
0
99

WHY THIS WORKS AS AN ANSWER
------------------------------
$_[0] = 0; in reset_to_zero reuses the chapter's own warn-box example
directly — $_[0] refers to the first element of @_, and because @_
ALIASES the caller's original variables rather than copying them
(per the chapter's own explanation), assigning to $_[0] reaches
straight through and modifies $x itself. Printing $x afterward
correctly shows 0, proving the caller's variable really did change,
exactly the surprising behavior the warn-box describes.

my ($n) = @_; in reset_to_zero_safe reuses the chapter's own
recommended fix — unpacking @_ into a fresh lexical variable with my
copies the VALUE out of @_ into $n, which is now a completely
independent variable with no connection back to $y. Setting $n = 0
afterward only changes that local copy, so $y remains 99 when checked
afterward.

The only difference between the two subroutines is whether the
argument was unpacked into a new my variable before being modified —
directly demonstrating the chapter's own point that "the standard
idiom of immediately unpacking with my ($a, $b) = @_; sidesteps [the
aliasing behavior] entirely."