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

FindAllRefs does not find simple destructuring property references? #6459

Closed
rob3c opened this issue Jan 12, 2016 · 2 comments
Closed

FindAllRefs does not find simple destructuring property references? #6459

rob3c opened this issue Jan 12, 2016 · 2 comments
Labels
Duplicate An existing issue was already created

Comments

@rob3c
Copy link

rob3c commented Jan 12, 2016

Hi, I like the convenience of destructuring, but I'm confused as to why FindAllRefs (via Shift+F12 in the TypeScript Playground and other editors) doesn't work as I expected it to in this scenario:

class A {
  foo: string; // type Shift+F12 inside foo here.
}

class B {
  syntax1(a: A): void {
    let { foo } = a; // F12 doesn't see this. Why not?
  }
  syntax2(a: A): void {
    let { foo: foo } = a; // F12 sees this.
  }
}

My understanding is that the syntax1 destructuring is just sugar for that in syntax2. The reference info is clearly available as shown in syntax2, so the current behavior may be intentional, suggesting that the compiler internally considers foo in syntax1 to just be the local identifier and ignores it.

However, if that's the case, I think there's an argument to be made that the syntax1 foo visually represents both the local identifier as well as the source property to developers. From this perspective, it's a surprising and misleading omission from the references list for the A.foo property.

So is this a bug or intentional? Is there really a good reason not to expose these (implicit-ish?) references to developers? Maybe it involves issues with renaming or similar behavior I haven't considered completely yet? Anyway, destructuring suddenly seems much less useful in light of this issue IMO.

Regards,
Robert

@RyanCavanaugh
Copy link
Member

I think this is the same root cause as #6312

@rob3c
Copy link
Author

rob3c commented Jan 13, 2016

Thanks for the quick reply, Ryan! That makes sense. Do you think it's close enough that we should close this issue then? Either way, it's nice to know it's not the intentional behavior and is therefore likely to work in the future :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants