Perhaps the part that is confusing you is that "load strict.pm file" is completely different from "enable strictures". You can enable strictures by changing the magic variable $^H during a BEGIN block, and get all the benefits of strict without actually using the file "strict.pm".

So... does this mean? If I "use v5.28" do I still need "use strict"?

In short, No.

The only difference that "use strict" gives vs. the strictures you get from "use v5.28" are that the global %INC will have an entry for "strict.pm", and the global symbol table %main::strict:: will have stuff in it, and you get the option of calling BEGIN { strict->import }. That last snippet would fail if nothing in your script ever loaded strict.pm.

On the upside, if every module switched from "use strict" to "use v5.28" you would save 0.0001 seconds of startup time by not needing to stat/open/read strict.pm.

Great explanations. Yes, I was confused about the difference between "load strict.pm file" and "enable strictures".

But once I actually went over strict.pm, I found another rabbit hole of multiple $^H "bits". So I checked which stricture bits are enabled by "use VERSION" vs "use strict". As it turns out, both set $^H = 256.

In fact, I'm not really sure how to set anything other than 256 (I've tried "use strict; no strict refs" etc), so this begs the further question of whether those strict tags actually work as advertised.

would save 0.0001 seconds of startup

Right. Depends on the device I guess; and now that I think about it, also on whether perl was actually installed with its core modules (e.g. libperl might have been statically linked into an app, but that's a whole different can of worms). Good to know.

The public-facing docs for this are in $^H; take careful note of the warning in the first paragraph.

The names and meanings of the values are available internally from grep 'define \+HINT' perl.h, starting around line 5939 at the time of writing. However you will normally see the values described there only during compilation time, since that is when they're supposed to take effect. Thus:

% perl -we 'use strict; BEGIN { printf "%#x\n", $^H }'
0x7e2
%
[download]

.. i.e. strict is enabled (STRICT_VARS, STRICT_SUBS, STRICT_REFS), it was enabled by an explicit use strict (EXPLICIT_STRICT_VARS etc), and I'm guessing BLOCK_SCOPE just means we're in a block (the BEGIN block).

I'm kind of rusty on the $^H details myself, so it might turn out that some other magic variable does more of the work these days. But yeah, the point is just that strict is nothing more than flags set in the interpreter during the compile phase of a file, and there are several ways to accomplish it.

use VERSION

Lexically enables all features available in the requested version as defined by the feature pragma, disabling any features not in the requested version's feature bundle. See feature

I never tried to use different versions inside the same file and I don't recommend it.

Here what I read (untested)

... it says that inside the scope of a use version all previous versions are to be considered irrelevant. IOW you can downgrade the features by going back to a lower version. ¹

There is ambiguity with certain pragmas like strict tho, when used simultaneously.

In the current implementation, any explicit use of use strict or no strict overrides use VERSION, even if it comes before it.

Those pragmas are implemented inside their own pm files, like strict.pm. And you can disable them with no

Those files "are not loaded" means they are not implicitly require d.

use version is implementing the effects directly and you can't rely on the pragma files being present. For instance by checking %INC

Again untested (I'm on Android right now) but this seems plausible.

> Why the hell is this written so opaquely?

The "opaqueness" is a result of the authors wanting to cover all rare edge cases.

I often wished that the perldocs were easier and covering the relevant 90% functionality in 10% text, while linking to the remaining 90% text covering the complicated edge cases most people avoid.

¹) see also feature#Lexical-effect