Forbid fat comma in declaration list

[epa]

In Perl the => operator is called the fat comma and behaves just like , except that it can implicitly quote its left hand side. But I suggest tightening the grammar slightly to require the ordinary comma in some places.

Currently this compiles without warning: sub f { my %x => (a => 5) } The programmer made a mistake and should have written = instead of the first =>.

Apart from golf, I don't believe the fat comma is used in practice as a C-style comma operator separating two statements. (Happy to be proved wrong.) I suggest a compile-time warning in the syntax category when => appears in a position it gets parsed as a C-style comma. Then those like me who prefer stricter checking can fatalize that warning. I would go further and advocate deprecating it, but a warning is probably controversial enough.

[dur-randir]

Apart from golf, I don't believe the fat comma is used in practice as a C-style comma operator separating two statements.

It actually is, a lot, in generated code. The difference between , and ; is not only semantical, but ; additionally creates an OP_NEXTSTATE entry in the optree, and traversing in/out of that op isn't free (you can think of it's cost as roughly the same as the cost of an addition, OP_ADD). So, when readability is not in question and one doesn't need to free temporaries using , is actually more efficient that using ; to separate statements.

Furthermore, I don't see any actual value even in warnings for such construct - it looks more appropriate for policies like Perl Critic.

[Grinnz]

I would agree simple cases could be caught by a perlcritic policy, but I'll also note it's extremely difficult to tell what context something is used in for perlcritic purposes, which is central to this determination.

[epa]

It actually is, a lot, in generated code.

I meant the fat comma => isn't used in practice as a C-style comma operator. The ordinary comma , is used of course.

As for perlcritic, the general point applies: surely nobody runs perlcritic on every edit-test cycle. That would slow down Perl to C++-like levels of turnaround. There is strong value in having things checked by perl itself, just as use strict is part of the language and not an external linter. I think this is a pretty simple case which falls on the correct side of the line for a builtin check. That's my opinion.

[dur-randir]

But 'use strict' catches things that can't be caught otherwise. It's like saying that !!!!$foo should be forbidden, since it's a nonsensical construct - but it's a part of the language syntax, like it or not.

[epa]

Indeed it is, that's why this feature request is framed as a change to the language syntax. I think a more restrictive syntax that doesn't allow => in every place where , can appear would make a more productive language to program in, because some common mistakes will then be caught sooner in the edit-test cycle.

[haukex]

I just wanted to point out I wrote a perlcritic policy for this once: https://www.perlmonks.org/?node_id=1180082 and @perlancar released it at Perl::Critic::PolicyBundle::PERLANCAR::Variables::ProhibitFatCommaInDeclaration