Re: Proposed feature: die on compile with undefined functions

On 1/29/26 12:11 PM, Dan wrote:
>
>     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.

I'm aware that there is a lot, and I've written quite a bit of it 
myself.  But I tend to only do those elaborate things in my CPAN 
modules, not in my everyday application code.  Likewise, someone using 
perl for everyday sysadmin scripting or data munging is unlikely to need 
dynamic resolution for the case of writing a function call without 
package qualifier.  (Reaching into a different package namespace would 
be exempt, because the user shouldn't be affected by implementation 
details of modules they use.  A module could decide to convert 
Foo::Bar::baz() to or from an autoload.)

> It's not needed for subs imported in the standard way, but for 
> example, when a subroutine is declared later in the file

I was thinking perl did some sort of two-pass parse where it identified 
those, but it seems I was mistaken and it is using the 
auto-vivification.  Sub::StrictDecl also has this problem since it's 
just checking each op as it gets built.  So I guess it can only be 
trapped at the end of the compilation of a file, or require users to 
pre-declare all out-of-order subs, which would be less convenient.


>  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
>
Optional strict flags would be nice.  Then people can decide whether to 
bundle it into their scope-setup modules like strictures or 
common::sense, etc.  I also think it could make sense as a "use v5.XX" 
feature bundle, but I wasn't suggesting breaking back-compat.

-Mike C.