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

Quick info shows method with type any[] at declaration and string[] at use #16643

Closed
ghost opened this issue Jun 20, 2017 · 3 comments
Closed
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@ghost
Copy link

ghost commented Jun 20, 2017

TypeScript Version: nightly (2.5.0-dev.20170619)

Code

/// <reference path='fourslash.ts'/>

// @noImplicitAny: true

////interface I { m(): string[] }
////
////const i: I = {
////    /*1*/m() { return []; }
////}
////
////i./*2*/m();

verify.quickInfoAt("2", "(method) I.m(): string[]");
verify.quickInfoAt("1", "(method) m(): string[]");

Expected behavior:

Test passes.

Actual behavior:

AssertionError: At 1: quick info text: expected '(method) m(): any[]' to equal '(method) m(): string[]'

@DanielRosenwasser DanielRosenwasser added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jun 20, 2017
@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jun 20, 2017

Here's what's happening here:

  1. The object is contextually typed by I
  2. The method m is contextually typed by the type of the property m within I
  3. The return expressions of m are contextually typed by the return type of the m within I
  4. The array literal is contextually typed, but arrays only change their type when contextually typed by a tuple type. You end up with a regular array whose element type is the widening undefined type.

@DanielRosenwasser DanielRosenwasser added Needs Investigation This issue needs a team member to investigate its status. and removed Needs Investigation This issue needs a team member to investigate its status. labels Jun 20, 2017
@JsonFreeman
Copy link
Contributor

JsonFreeman commented Jun 21, 2017

Would it be reasonable for an empty array literal with a contextual type to just acquire the element type as its own? Even if the contextual type isn't a tuple

That said, I think the current behavior is reasonable. After all, the method does return an empty array.

@mhegazy
Copy link
Contributor

mhegazy commented Aug 17, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy mhegazy closed this as completed Aug 17, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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

3 participants