Repository navigation
Return with a bareword compiles under strict #21716
Description
Activity
This has to do with the way list ops are parsed. One of the possible productions for a listop in the grammar is:
listop : LSTOP indirob listexprwhere LSTOP is the op (OP_RETURN, OP_PRINT etc),
indirobis a file handle, andlistexpris the list, this production is used to parse code like:print HANDLE LIST;It also parses other code like:
atan2 HANDLE y, xwhich parses, but is then rejected in the op's check function (which is Perl_ck_fun, used by many other ops).
I'll look at a fix.
Reacted by Elvin Aslanov- added a commit that references this issue
on Dec 18, 2023 - added 2 commits that reference this issue
on Dec 18, 2023 - added 2 commits that reference this issue
on Dec 19, 2023 I expected to get an error about invalid bareword under strict mode, same as without return.
(F) While certain operators allow you to specify a filehandle or an "indirect object" before the argument list, return isn't one of them.
Why not?
Worth mentioning that it's also because
returncould be implicit (producing different results).Why not?
Because it's documented not to do so:
return EXPR return Returns from a subroutine, "eval", "do FILE", "sort" block or regex eval block (but not a "grep", "map", or "do BLOCK" block) with the value given in EXPR. Evaluation of EXPR may be in list, ...The other operators that take an indirect object are output operators like print that treat the object as a file handle, what do you expect
returnto do with an indirect object?Worth mentioning that it's also because `return` could be implicit (producing different results).I'm not sure what you mean here, at first I thought you might mean returning by running off the end of a function, but that's unrelated to the return operator.
Why not?
Because it's documented not to do so:
return EXPR return Returns from a subroutine, "eval", "do FILE", "sort" block or regex eval block (but not a "grep", "map", or "do BLOCK" block) with the value given in EXPR. Evaluation of EXPR may be in list, ...The other operators that take an indirect object are output operators like print that treat the object as a file handle, what do you expect
returnto do with an indirect object?Worth mentioning that it's also because `return` could be implicit (producing different results).I'm not sure what you mean here, at first I thought you might mean returning by running off the end of a function, but that's unrelated to the return operator.
Ah no, I meant if we omit
returnat the end of a function there won't be issues. This was confusing the OP (poster), apparently. I thought it'd be good to mention that in the message (a fact that setsreturn apart from the other OPs).Thank you very much for the commits 👍🏻
Ah no, I meant if we omit
returnat the end of a function there won't be issues. This was confusing the OP (poster), apparently. I thought it'd be good to mention that in the message (a fact that setsreturn apart from the other OPs).I'm not confused, I understand implicit return may not work the same as explicit. I just did not think return should mask errors like that. But I'd rather not to depend on implicit behavior in case of returning.
Thanks for the fix, Tony.
Description
return sum map { ... } @listseems to compile OK under strict without the import ofList::Util::sumand returns a filehandle and a mapped list.Steps to Reproduce
This program shows the behavior:
The actual error occurs only after you remove
return. Removingmapcauses it to report a warning, but it still runs.Expected behavior
I expected to get an error about invalid bareword under strict mode, same as without
return.Perl configuration
Behavior is consistent on both perl 5.10.1 and 5.38.2.