Re: Proposed feature: die on compile with undefined functions

On Thu, Jan 29, 2026 at 9:41 AM Michael Conrad <[email protected]> wrote:

> On 1/29/26 5:52 AM, Philippe Bruhat (BooK) wrote:
> >> *4. Here are potential problems*
> >>
> >> I am unaware of any.  I just want something that will happen anyway to
> >> happen sooner to save time.  This change *shouldn't *be buggy.
> > The problem is see is that it's extremely hard to detect if a function
> > will be defined by the time Perl tries to call it:
> >
> >      use v5.42;
> >      require List::Util;
> >      List::Util->import("max");
> >      say max( 1..10, -1..7);
> >
> > All of those lines happens at run time, and max is available by the time
> > it's called. At the end of compilation, though, max is not defined.
> >
> While lots of dynamic ways exist to define a sub before it gets used, I
> would argue that in a vast majority of cases by ordinary users, the sub
> will either be declared in the body of code itself, or imported into
> their package in the BEGIN phase, or imported it into their scope
> lexically by some means.  It seems reasonable to me that there could be
> a perl feature to be strict about wanting the sub to be declared.
> Something like `use experimental 'strict_declared_subs';`
>
> It seems like it might be easy to add a flag so that when parser sees
> `foo(1,2,3)` and checks lexically and in the package stash and doesn't
> find the sub, instead of auto-vivifying it, it could just croak.  What
> non-esoteric cases would that break?
>

I think you may be surprised by the volume of code, on and off CPAN, which
depends on this ability to defer function name resolution to runtime. It's
not needed for subs imported in the standard way, but for example, when a
subroutine is declared later in the file (could be common in module
functions that call each other) or when a module is not even loaded until
runtime for various reasons. It's not something that could ever be made a
default feature or strict flag this millennium, but I could see the case
for an optional strict flag (a mechanism which we don't currently have[1]).
Sub::StrictDecl as previously mentioned gives you this behavior now.

[1] https://github.com/Perl/perl5/issues/18543

-Dan