Skip to content

Return type annotation missing error #1146

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
NoelAbrahams opened this issue Nov 13, 2014 · 2 comments
Closed

Return type annotation missing error #1146

NoelAbrahams opened this issue Nov 13, 2014 · 2 comments
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead

Comments

@NoelAbrahams
Copy link

Hi,

VS: 2013 Update 4
TS: 1.3

Here's some code that compiles correctly:

class Base {

    foo() {
        return this;
    }
}

class Derived extends Base {

    foo() {
        return super.foo();
    }
}

Here's some other code that fails:

class Base2 {

    foo() {
        return this;
    }
}

class Derived2 extends Base2 {

    // 'foo' implicitly has return type 'any' because it does not have a 
    // return type annotation and is referenced directly or indirectly in 
    // one of its return expressions.
    foo() {
        return <Derived2> super.foo();
    }
}

I'm aware that a bug with implicit-any and recursive methods has been fixed, but to me it's pretty clear that the return value for Derived2.foo is Derived2.

@mhegazy
Copy link
Contributor

mhegazy commented Nov 13, 2014

The issue is not no-implicit-any. The problem is the compiler was resolving g the type of Dervived2, that is trying to build a structure for how objects of this type look like. It figured that it has a foo method, then it tried to get the signature for it. Since it does not have a return type annotation, the compiler then needs to look at all return statements to get the return type. In this case it is the type assertion that defines the type. Now here is the issue we do not really know what dervided2 is, cause we were just trying to figure this our. In these situations the compiler breaks the tie by giving it an any type.

The warning basically tells you the compiler could not infer the type as you write it and set it to any. An explicit type annotation should do the trick.

Hope that helps.

@mhegazy mhegazy closed this as completed Nov 13, 2014
@mhegazy mhegazy reopened this Nov 13, 2014
@RyanCavanaugh RyanCavanaugh added the By Design Deprecated - use "Working as Intended" or "Design Limitation" instead label Nov 26, 2014
@RyanCavanaugh
Copy link
Member

Hopefully we will eventually figure something more concrete out here, but for now the compiler is still in a recursive type inference situation when it is trying to decide whether or not the operand of the type assertion is assignable to the asserted type, which triggers a 'recursive any'.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead
Projects
None yet
Development

No branches or pull requests

3 participants