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

Pattern Catching uses let instead of const #1487

Open
bbrk24 opened this issue Oct 22, 2024 · 4 comments
Open

Pattern Catching uses let instead of const #1487

bbrk24 opened this issue Oct 22, 2024 · 4 comments
Labels
lint Generated code can cause eslint errors

Comments

@bbrk24
Copy link
Contributor

bbrk24 commented Oct 22, 2024

ESLint doesn't like that

@edemaine
Copy link
Collaborator

Civet uses let all over the place for refs. Is this really the first time it's come up with a single assignment? I'd recommend disabling thay rule.

In this case, it's implementing catch's normal semantics (you can assign to e).

@bbrk24
Copy link
Contributor Author

bbrk24 commented Oct 22, 2024

Is this really the first time it's come up with a single assignment?

Usually it's either multiple assignment (x := try f() catch g()) or assigned in expression position (if foo := bar()), so the error hasn't been applicable before now. It still has the ability to be meaningful, e.g. forbidding .= where := would suffice.

@edemaine
Copy link
Collaborator

Ah, OK, the rule is indeed useful for Civet if it doesn't apply to assignments in expression position. I guess the question here is whether to detect whether const would suffice (probably doable... but might need some scope work, to ignore assignments to shadowing variables of the same name), or somehow get eslint to ignore these (via a comment, or by doing the assignment in expression position, or...).

@bbrk24
Copy link
Contributor Author

bbrk24 commented Oct 22, 2024

Actually, I just discovered another situation in which this error can trigger:

->
  return = 5
  foo()

The return ref is never used again so it "should" be a const. The annoying thing about both of these is that I can't even manually add // eslint-disable-next-line prefer-const -- in the return case it gets placed after the let ret; declaration, and in the catch case it's eaten entirely.

@edemaine edemaine added the lint Generated code can cause eslint errors label Dec 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lint Generated code can cause eslint errors
Projects
None yet
Development

No branches or pull requests

2 participants