Open epa opened 4 years ago
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.
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.
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.
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.
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.
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
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.