Perl 5.25.12 makes loading failures more precise
The April development snapshot changes when require errors display the module search path. It also connects failed local do statements with the removal of dot from the defaults.
An error message can send an investigation in the wrong direction when it lists configuration that the failing operation never used. Perl 5.25.12 changes require diagnostics so that they no longer display @INC when the call did not scan it. Its release notes also describe the related change for a file request instead of a module request. The release tag records April 20, 2017. This snapshot makes the explanation of a loading failure better match the operation that failed.
The timing matters because the development series has changed its default treatment of the working directory. A missing file may now reflect an assumption about . in the search list, but not every loading failure is a search-list problem. Printing the same list for unrelated cases obscures that distinction. Diagnostic accuracy helps separate a deliberate filename from a name the interpreter must resolve.
I appreciate this kind of change in a language used for short programs. A compact script often leaves the interpreter's own diagnostics to explain a failure. Those messages need to identify the relevant behavior without implying that every missing dependency has the same cause.
Module names and filenames are different requests
The function documentation in this release explains the transformation applied to a bareword module name. In require Foo::Bar, Perl supplies the .pm suffix and replaces :: with /. The resulting lookup searches for Foo/Bar.pm in @INC. The spelling in the program names a module, while the loader constructs the corresponding filename.
Quoting the apparent name changes those semantics. require "Foo::Bar" searches for a file named Foo::Bar, without performing the bareword transformation. A variable containing that string likewise does not acquire the bareword behavior. These are documented distinctions in the argument to require, so similar-looking source expressions can ask for different files.
That difference explains why a diagnostic needs to reflect the actual request. A displayed module search path is relevant when the interpreter has attempted a search through it. When the operation bypasses that search, displaying the path suggests an explanation that does not describe the execution. The snapshot removes that suggestion in the cases identified by its release notes.
The change does not make every filename argument independent of @INC. The documentation explicitly shows a quoted Foo::Bar filename being sought there. For these diagnostics, the important condition in the release note is whether the call scans the list. The argument spelling and the actual search behavior therefore need to be considered together. Treating the change as a rule that all quoted arguments bypass module lookup would introduce another incorrect simplification.
The local-file warning identifies a changed default
The release also documents a do warning connected to the removal of . from the default @INC. Its diagnostic recommends an explicit ./ filename when that is what the caller intended. The message addresses an apparent contradiction in an old script, where the file exists beside the process but its bare name fails to load.
The documented forms illustrate the distinction:
do 'stat.pl';
do './stat.pl';
A bare filename asks do to search @INC. The explicit relative path identifies the file in the current directory. Historically, the default . entry often made those forms equivalent in practice. Removing it means that the location must be stated when the second behavior is intended.
The diagnostic cannot decide whether that local file is appropriate to execute. Supplying ./ expresses a choice about the source of code, and the directory's contents still determine which code that path reaches. The warning's contribution is to explain the changed lookup and suggest the relevant form. It leaves the application's intended trust policy to its author.
Loading still has a success contract
Correcting lookup does not finish the job of including a file. The function documentation says that a required file must return a true value to indicate successful execution of initialization code. It recommends ending the file with 1; unless a true final value is otherwise assured. An edited module can accidentally change its last expression, which makes an explicit final true value useful.
Perl also avoids including a file twice under the same specified name. That behavior distinguishes require from do, which reparses a file each time. A caller choosing between the operations is choosing execution semantics as well as a way to find a file. Neither the new warning nor the shorter error output changes those documented responsibilities.
I regard the April snapshot as a useful continuation of the loading-policy work. Removing a default can expose several different assumptions at once, and precise diagnostics make those failures distinguishable. A missing module can point to the locations actually searched, while a request that did not scan those locations no longer prints them as if it had.