I beg to differ. Perl has quite a few warnings of this very nature, where a syntax is perfectly valid but probably not what the programmer meant. Some examples (see perldiag for more details and a more complete list):

So sorry but you're wrong :)

Just cause perl has some that use "probably" doesn't mean they belong in there, cause it doesn't :D they're humans just like me

Specifically this doesn't belong but its super super old

Possible attempt to put comments in qw() list 
Possible attempt to separate words with commas
[download]

I'm sure the larry or whomever could come up with the reason for including it, but I think its stupid cause how can you be surprised when you type that stuff up and then @foo ends up contains both "#" and "," ?

First time you run the program you discover , hey, qw works exactly as advertised, who knew the manual doesn't lie but no , instead you get annoying warning, cause some tiny percent of learners (0.0000001%) don't know basic debugging (verify the contents of your variables).

This has annoyed me since I first learned perl. warnings.pm is for work not 5th grade programming class .

This one should be phrased better than Possible memory corruption: %s overflowed 3rd argument but whats done is done

I think this is better memory overflow: %s overflowed 3rd argument cause if "memory overflow" doesn't tell you "uh-oh" then surely use diagnostics; would explain it may be "possible memory corruption"

Possible precedence issue with control flow operator should just be a fatal syntax error , cause there ain't no reason other than obfuscation to allow this nonsense

Another wording problem Possible unintended interpolation of %s in string, Should read Cannot interpolate %s in string

This should be fatal /%s/ should probably be written as "%s" cause obfuscation/japh is the only reason to this nonsense  join m/word/ , 1,2,3,4

Possible unintended interpolation of $\ in regex should be fatal cause it doesn't warn on ther "metacharacter" global variables

And my favorite Possible precedence problem on bitwise %s operator should read DAMN SON YOU MUST BE A PRECEDENCE GENIUS TO WRITE %s with bitwise %s operator. THE LARRY SALUTES YOU!!

warnings is warnings its not extra linty warnings

But yeah what do i know

When something is (indeed) a warning, there's always the possibility that the warning is incorrect in that it does not align with what the user means. But this alone does not invalidate the fact said warning is useful. For example, using another warning that has "possibly" in its wording:

% perl -Mstrict -MFoo -we'$Foo::bar = 1'
Name "Foo::bar" used only once: possible typo at -e line 1.
[download]

Does the programmer make a typo or does he really mean setting $Foo::bar? perl can never know for sure, so it just emits a warning instead of an error message. The programmer can disable the warning if he knows that he is doing what he wants. Continuing with another warning which you mentioned:

our @EXPORT = qw(
    foo bar baz
    qux quux
);
[download]

and a few months later:

our @EXPORT = qw(
    foo bar baz
    qux quux
    corge grault
    # not sure we want to export these by default because the name is 
+rather common, 
    # but let's do it anyways for now
    thud jet
);
[download]

Are you sure that you, even if you're already a veteran, will never make this mistake? perl is being helpful here by emitting a warning. If perl turns out to be wrong here, just disable the warning lexically.

But I guess there's always the debate of how much should perl offer helping hands and treat the programmer like a novice or stupid person. But hey, humans *are* stupid :)

and a few months later: our @EXPORT ... Are you sure that you, even if you're already a veteran, will never make this mistake?

comments next to a space separated list of barewords?

Yes, I am 100% sure I will never make this mistake

the same as I am sure I will never type "#oops," and not want the "#" and "," as part of the string, and then come back 20 years later and type "# oh yeah , yeah yeah yeah " and expect to get a list instead of a string

but even if I made the mistake, Exporter whose job it is to handle @EXPORT, would catch this the first time the module was used, like when the tests were run, and die  Can't export symbol: # at junk.pl  line 21

But hey, documenting design indecision in comments? That doesn't belong in comments, it belongs in official documentation, so I'm more than 100% sure, i'm 200% sure :D

Does the programmer make a typo or does he really mean setting $Foo::bar? When something is (indeed) a warning, there's always the possibility that the warning is incorrect in that it does not align with what the user means.

congratulations, , even I won't argue that one doesn't belong, but only because its exceptional

Solution to that one isn't disable warnings lexically its  $double::up = $double::up = "for silence";

Anyway , haukex was faster to perlcritic policy, but I would have used xpaths instead

perlcritic is where this type of extra help belongs , warnings is all full up

Disingenuous