Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong interpretation of { a: 1 }['a'] in the REPL (BlockStatement v.s. ExpressionStatement) #45964

Closed
cola119 opened this issue Dec 24, 2022 · 5 comments
Labels
repl Issues and PRs related to the REPL subsystem.

Comments

@cola119
Copy link
Member

cola119 commented Dec 24, 2022

Version

v19.2.0

Platform

No response

Subsystem

No response

What steps will reproduce the bug?

Evaluate { a: 1 }['a'] in the REPL

$ node
> { a: 1 }['a']

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior?

$ node -p "{ a: 1 }['a']"
[ 'a' ]
$ node
> { a: 1 }['a']
[ 'a' ]

What do you see instead?

$ node -p "{ a: 1 }['a']"
[ 'a' ]
$ node
> { a: 1 }['a']
1

Additional information

The REPL tries to wrap the code that starts with { in parentheses eagerly ('eager wrapping' was introduced at #31943) and { a: 1 }['a'] is converted into an ExpressionStatement ({ a: 1 }['a']) that is evaluated to 1. However, technically speaking, { a: 1 }['a'] should be parsed as the combination of a BlockStatement {a:1} and an ExpressionStatement ['a'], yielding a result of ['a'].

The results of { a: 1 }['a'] in other runtimes:

  • ChromeDevTools: ['a']
  • Safari WebInspector: ['a']
  • Deno REPL: 1
@cola119 cola119 added the repl Issues and PRs related to the REPL subsystem. label Dec 24, 2022
@aduh95
Copy link
Contributor

aduh95 commented Dec 25, 2022

Maybe it should print the technically correct answer and also print out a warning that the user may want to wrap into parentheses to get what they actually want?

@addaleax
Copy link
Member

I think the current behavior is fine -- the REPL is a human-facing function of Node.js, and should do what users expect it to do most of the time, not necessarily what is technically correct. And I think when a user inputs something that is a valid expression, it's reasonable to assume that they also expect it to be evaluated as an expression, not a full JS program.

@Dsstefanov
Copy link

I would say the expected behaviour is to get converted in ExpressionStatement rather than a BlockStatement for a couple of reasons:

  1. Current developers are already familiar with the functionality of it being parsed as ExpressionStatement.
  2. If you use EOL operator it will get parsed according to your expectation to BlockStatement
  3. Like @addaleax mentioned if a valid expression is inserted it is intuitive it will get parsed as ExpressionStatement.

@bnoordhuis
Copy link
Member

For historic perspective: the current behavior was deliberately introduced 12 years ago in commit b45698e because the default behavior kept confusing new users again and again and again.

@bnoordhuis
Copy link
Member

Closing. The consensus is we're not going to change that.

@bnoordhuis bnoordhuis closed this as not planned Won't fix, can't repro, duplicate, stale Jan 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
repl Issues and PRs related to the REPL subsystem.
Projects
None yet
Development

No branches or pull requests

5 participants