Skip to content

Simplify strict.pm #22848

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 4, 2025
Merged

Simplify strict.pm #22848

merged 1 commit into from
May 4, 2025

Conversation

ap
Copy link
Contributor

@ap ap commented Dec 8, 2024

strict.pm is slightly confusing to follow. Restructuring it to make it more legible makes it more apparent that there are some optimizations to be had, which make it no harder to understand, so I’ve taken that opportunity as well.

  • This set of changes does not require a perldelta entry.

@jkeenan
Copy link
Contributor

jkeenan commented Dec 10, 2024

Needs a version bump in lib/strict.pm.

@ap
Copy link
Contributor Author

ap commented Dec 12, 2024

@jkeenan Yes, but that’s the least of the problems. Turns out strict::bits() does get used as API so I have to redo the whole thing a bit differently.

@ap
Copy link
Contributor Author

ap commented Dec 12, 2024

(OTOH this has unearthed the fact that some of the use of strict::bits() as API predates and contradicts some of the changes made to it over time – and cleaning that up will be a good thing.)

@bulk88
Copy link
Contributor

bulk88 commented Jan 11, 2025

new docs are always good

@ap ap force-pushed the ap/simpler-strict branch 2 times, most recently from 497a220 to 1766feb Compare February 2, 2025 04:10
lib/strict.pm Outdated
@@ -59,14 +61,15 @@ sub bits {

sub import {
shift;
$^H |= @_ ? &bits : all_bits | all_explicit_bits;
$^H |= @_ ? &bits | $explicit_bits : all_bits | all_explicit_bits;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

&bits | $explicit_bits relies on left-to-right evaluation in | since &bits resets the value of $explicit_bits. Does perl guarantee left-to-right evaluation in non-shortcutting operators?

@haarg
Copy link
Contributor

haarg commented Feb 2, 2025

Perhaps an alternative:

diff --git i/lib/strict.pm w/lib/strict.pm
index ad31edcacf..0579fce7d2 100644
--- i/lib/strict.pm
+++ w/lib/strict.pm
@@ -42,8 +42,7 @@ sub bits {
     my @wrong;
     foreach my $s (@_) {
         if (exists $bitmask{$s}) {
-            $^H |= $explicit_bitmask{$s};
-
+            $bits |= $explicit_bitmask{$s};
             $bits |= $bitmask{$s};
         }
         else {
@@ -66,7 +65,9 @@ sub unimport {
     shift;
 
     if (@_) {
-        $^H &= ~&bits;
+        my $bits = &bits;
+        $^H &= ~$bits;
+        $^H |= all_explicit_bits & $bits;
     }
     else {
         $^H &= ~all_bits;

@ap ap force-pushed the ap/simpler-strict branch 2 times, most recently from 41e3117 to 8bf9adf Compare February 4, 2025 03:31
This improves the code in two ways:

1. Considering strict::bits is used by B::Deparse and vars.pm as
   unofficial API, the function having this side effect is arguably
   a latent bug even if it doesn’t break those callers.

2. It is harder to follow the intended logic when the function modifies
   $^H itself but also returns a value for the caller to apply to $^H.
@ap ap force-pushed the ap/simpler-strict branch from 8bf9adf to 0ff126f Compare February 4, 2025 03:32
@ap
Copy link
Contributor Author

ap commented Feb 4, 2025

@mauke I am pretty sure evaluation order is effectively fixed and would break a lot of stuff if it were to change, but point taken.

@haarg The only thing I dislike about that is that it changes the meaning of the return value of bits, which I’d rather avoid, even if it’s not official API.

@ap ap merged commit 065bd19 into blead May 4, 2025
@ap ap deleted the ap/simpler-strict branch May 4, 2025 12:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants