Are you wanting perlcritic to ignore issues with that particular line? If so, the BENDING THE RULES section of Perl::Critic's documentation provides details on how to get perlcritic to ignore one or more lines of code. I have never used perlcritic, so I have no idea if that is "best" or "only" way to achieve the same thing.

Thanks dasgar. The problem is other uses of autoderef are showing up in the logs and that's what I want to fix. I'm not sure if this one is showing though so will need to investigate more...

Based on the perlcritic message autoderef is deprecated [...]  Use of each/keys/pop/push/shift/splice/unshift/values on a reference is an experimental feature..., it seems to think your key called 'shift' is the shift() builtin. Does the same thing happen if you renamed 'shift' to 'working_shift' in the example code (sorry, I don't have perlcritic, otherwise I'd try before posting). Alternately, what if you used $hash->{'shift'}, to make sure it disambiguates for perl and perlcritic

... Actually, thinking about it, it might also be the method named 'shift' which is triggering perlcritic to complain about it, even though perl knows you're referencing the method, not the builtin. Either way, (temporarily) renaming the 'shift' attribute should tell you whether that's the problem.

This part:

shift( $hash->{shift} )
[download]

... confuses perlcritic into thinking you're doing:

shift($arrayref)
[download]

... and it wants you to do:

shift(%{$arrayref})
[download]

... instead. Performing array function directly on arrayrefs is an experimental feature which sucks and is stupid.

It's not an experimental feature; it's a removed feature. (https://perldoc.pl/perlexperiment#Array-and-hash-container-functions-accept-references) However, this case isn't actually trying to use the feature or the shift function, it's just mistaken identity.

Edited (again): As haukex points out in his reply, I've apparently just been paranoiac without a good reason. There's nothing wrong with an unquoted shift within braces, the following advice can safely be scratched.

if($hash->{'shift'})     { $Person->shift( $hash->{'shift'} );  }
[download]

The Perl parser could confuse the bareword shift in the braces with its core function shift instead of converting it to a string.

I'm pretty sure that Perl will always take $hash{shift} to mean the hash key "shift", although adding any other characters will change that ($hash{+shift}, $hash{shift()}, etc.) See also.

I'm pretty sure that Perl will always take $hash{shift} to mean the hash key "shift", although adding any other characters will change that ($hash{+shift}, $hash{shift()}, etc.)

I guess you're right. I've posted from memory because I thought that I had been bitten by something like that in the past. However, I failed to find any evidence, nor could I construct any test supporting my case. Quite on the contrary, I found that some other characters won't even prevent stringification, as is demonstrated by Tk's habit of having $hashref->{-option} reliably interpreted as $hashref->{'-option'}.

Thanks for the correction!

Nope. A false positive is a false positive. Thats a poorly written critic policy

Obviously I need to change the name of the key and the method (and db column, and....), but that's heavy so leaving it for the moment.

It is important to mention the Perl version that you are using. In Perl 5.26.2 MSWin32-x64-multi-thread I receive different compilation errors then yours.

E.g. Experimental shift on scalar is now forbidden at ... line .., near "shift ;"

I believe the error is cause by the contents of $hash and you are not showing the contents which makes it hard to understand the problem you are looking at. Also, the actual shift operation that causes the problem is not shown in your example code. The error you mentioned does not show where it is coming from.

And AFAICS there is no problem in your example code except for the fact that I personally would never use hash keys and method names that belong to the base instruction set of the Perl programming language.

I don't think it is caused by the contents of $hash as the same error is reported when $Person->shift('one') is called.

I think it is caused by the use of the keyword 'shift', and it is picked up by perlcritic as an attempt to dereference. And yes, I would never use that as a hash key either - note: I didn't write this code

Gotta check if there is a previous sibling that is a token operator "->"

$Buggy # and silly
->shift # billy :)
( $FalsePositive );
[download]

The question is what perlcritic policy is complaining/broken?

 $ perlcritic --brutal --verbose=9 ....


[Freenode::DeprecatedFeatures] autoderef is deprecated at line 2, near
+ '$Person->shift( $foo );'.  (Severity: 4)

[Freenode::DeprecatedFeatures] autoderef is deprecated at line 4, near
+ '$Person->shift( $hash->{shift} );'.  (Severity: 4)
[download]

So this is a bug in Perl-Critic-Freenode-0.027 / Perl::Critic::Policy::Freenode::DeprecatedFeatures

A shift method isn't tested in https://metacpan.org/source/DBOOK/Perl-Critic-Freenode-0.027/t/Freenode/DeprecatedFeatures.run

shift(@goodArray);
shift @$goodRef;
shift @{$goodRef};
shift(@{$goodRef->{bar}[5]});
shift $goodRef->{bar}[5]->@*;
shift;
shift();
shift($bad->[5]);
print +shift $bad;
$Buggy->shift( $FalsePositive );
$Buggy->shift( $FalsePositive->{shift} );
[download]