feat: always infer function call when args empty or have comma #3378
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proposed PR to resolve #3358. It interprets
EXPR()
andEXPR(..., ...)
as function calls regardless of whatEXPR
is, rather than syntax errors unlessEXPR
is a symbol or accessor. To enable this syntax to cover unary function calls as well, it allows a trailing comma in argument lists, meaningexp(3,)
is now a legal synonym forexp(3)
. With these conventions, you can write(f(x) = x+1)(6,)
to get 7.I would totally be open to other syntaxes that would allow one to call a function that was the result of an expression (rather than a direct symbol or accessor), but I wanted a PR available so that you could try this one in practice.
Note that re-allowing expressions that return functions to be called makes a small handful of the security tests no longer simply syntax errors. However, all such tests still show these exploits ineffective, due to other security measures (that were likely already in place when the prior syntax for calling a function returned from an expression,
(EXPR)(3)
, was eliminated in favor of implicit multiplication).Looking forward to your thoughts.