Skip to content

variable is declared but its value is never read when destructing array #31357

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

Closed
jerrygreen opened this issue May 12, 2019 · 6 comments
Closed
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@jerrygreen
Copy link

jerrygreen commented May 12, 2019

When destructing array, I want some variables/const to be declared but explicitly make them unused. Typescript has a feature of underscoring the unused parameters for functions:

const f = (a, _b) => a`)

But it doesn't work for array destruction:

const [a, _b] = [1, 2]

TypeScript Version: 3.5.0-dev.20190512

Search Terms:

  • declared but never used noUnusedLocals

Code

const [a, _b] = [1, 2]
export default a

Expected behavior:

No error

Actual behavior:

Got an error, '_b' is declared but its value is never read:

Playground Link:

Here's it, OR use my gist:

git clone [email protected]:240a015b7833fd6628c5c8ccfaa7938e.git test-ts-unused
cd test-ts-unused
tsc

Related Issues:

@ShadabFaiz
Copy link

Well, you are clearly specifying the option "noUnusedLocals": true in the compilerOption. So it is expected behavior. turn it off if you want the error message to go away. Also, if you need to only a, then why not just deconstruct only for a like:

const [a] = [1, 2];

@jerrygreen
Copy link
Author

@ShadabFaiz in this example:

const f = (a, _b) => a

_b does not count as "unused", it is a feature - your variable may start with _ - then it's explicitly said "it is unused but don't complain about it please" (it is, overall, a good old practice to name unused variables like so). Try to make it like so:

const f = (a, b) => a

And you'll notice the same error about b.

So what I mean - it is working for functions' arguments only. For destructured array syntax it's not working. That's the problem.

@RyanCavanaugh
Copy link
Member

The _ behavior for parameters is there because some code depends on function .length and because leading parameters are required.

There's no corresponding need to destructure a trailing array value, and "leading" destructure targets aren't required (i.e. const [, a] = [1, 2]; is legal, where as function f(, a) is not).

If there's some reason you need to destructure the second element that we're not aware of, we can revisit, but barring that it's simply a correct error to say that this variable is unused and there isn't a reason to create a carve-out for that rule.

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label May 13, 2019
@jerrygreen
Copy link
Author

Ok, it's "working as intended", but it should be intended to work in a better way (i.e. for arrays in the same way as for function, even if you have workarounds for dustructuring arrays with const [, , , someVar] = someArr weird syntax). Why it's better? You're losing the variable names right now.

I've added a new issue, using a "Feature Request" template, with more explanations: #31388

This one, I think, we may close

@nevir
Copy link

nevir commented May 14, 2019

If there's some reason you need to destructure the second element that we're not aware of, we can revisit, but barring that it's simply a correct error to say that this variable is unused and there isn't a reason to create a carve-out for that rule.

I think there's a pretty strong case to be made for allowing unused _ prefixed variables:

const [_foo, _bar, baz] = someArgsArray;

They provide more obvious documentation about the structure of the array/tuple. In addition, more than a handful of bare commas can be extremely hard to follow, and error prone (especially with homogeneous arrays).

@pauldraper
Copy link

Why it's better? You're losing the variable names right now.

Unused variable names

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants