If you've got a list of valid apt numbers probably the most efficient thing to do would be create a hash and use that to validate

The danger here is when a valid apartment number (either now or in the future) is also a valid year.

The OP appears to have listed 2022 as being an apartment number - and that's certainly a valid year...

if( exists $valid_apt_numbers{ $digits_4 } ) {
  $text =~ s{\b($digits_4)\b}{<a href=YADDAYADDA</a>}xmsg;
}

If $digits_4 is defined as in the OP, i.e., as a Regexp object, I don't see how its stringization will ever match any key in %valid_apt_numbers, all of which are "unit" numbers of the format '1001', '2202', etc.

DERP, good point; for some reason I read that as having the matched number in it. Handwaving attempt below using /e and adding a bit of logic to the RHS of the substitution would work. Still has the problem of the fuzziness that it's non-trivial to be sure you're only pulling apartment numbers with just the regex and not getting years or what not.

A better solution would be to annotate explicitly in the source text as mentioned elsewhere. Better still use a real templating solution to explicitly mark up things. (e.g. TT like See more about [% apt_link( 1002 ) %] )

#!/usr/bin/env perl
use 5.034;

my $text = <<'EOT';
This is an appt: 1203
So is 1001.
But 8675 is not.
EOT
chomp($text);

my $digits_4_re = qr{ (?<!-)\b[0-9]{4}\b(?!-) }xms;

my %valid_appt_numbers = ( 1001 => 1, 1203 => 1, );

sub _anchor_if_apt {
    my $candidate = shift;

    if ( exists $valid_appt_numbers{$candidate} ) {
        return _anchor_for_num($candidate);
    } else {
        return $candidate;
    }
}

sub _anchor_for_num {
    my $unit = shift;
    return qq{<a href="apartment.pl?do_what=view&unit=$unit"><b>$unit<
+/b></a>};
}

$text =~ s{($digits_4_re)}{ _anchor_if_apt( $1 ) }xsmeg;

say $text;

exit 0;

__END__
$ perl texty.plx
This is an appt: <a href="apartment.pl?do_what=view&unit=1203"><b>1203
+</b></a>
So is <a href="apartment.pl?do_what=view&unit=1001"><b>1001</b></a>.
But 8675 is not.
[download]

The cake is a lie.
The cake is a lie.
The cake is a lie.

A better solution would be to annotate explicitly in the source text [or] use a real templating solution ...

I strongly agree. Just too much ambiguity about whether 2023 is a unit number, year, part of a phone number or address, etc., etc. And then there are the unit number variations that will surely be introduced sooner or later.

---

Give a man a fish:  <%-{-{-{-<

while (($pointer = $sth->fetchrow_hashref) && ($current_count <= $stop
+count)){
            $current_count++;
            if ($current_count >= $startcount && $current_count <= $st
+opcount) {



my %valid_apt_numbers;
for my $unit ( split( /,/, q{1001,1002,1003,1004,1101,1102,1103,1104,1
+201,1202,1203,1204,1301,1302,1303,1304,1401,1402,1403,1404,
 1501,1502,1503,1504,1601,1602,1603,1604,1701,1702,1703,1704,1801,1802
+,1803,1804,1901,1902,1903,1904,2001,2002,2003,2004,
 2101,2102,2103,2104,2201,2202,2203,2204,2301,2302,2303,2304,2401,2402
+,2403,2501,2502,2503,2504,2505} ) ) {
  $valid_apt_numbers{ $unit } = 1;
}

if( exists $valid_apt_numbers{ $digits_4 } ) {
  $text =~ s{\b($digits_4)\b}{<a href="apartments.pl?do_what=view&unit
+=$1"><b>$1</b></a>}xmsg;
}

print qq~
$text
~;


    }
}
[download]