Regression in BCT when type uses 'this' in a member initializer during type inference

[RyanCavanaugh]

interface PromiseHolder {
    promise: Promise<any>;
}

class Promise<T> {
    constructor(elem: T) { }
}

class Alpha implements PromiseHolder {
    promise: Promise<PromiseHolder>;
}

class Beta implements PromiseHolder {
    // Must use 'this' in the initializer here
    // Cannot have Promise<PromiseHolder> type annotation
    promise = new Promise<PromiseHolder>(this);
    extra: string;
}

var arr: PromiseHolder[];
var a = new Alpha(), b = new Beta();
arr = [a, b]; // Error in new compiler only: cannot convert {} to PromiseHolder

// Sanity checks
a = b; // OK, Beta is subtype of Alpha
arr[0] = a; // OK, Alpha is subtype of PromiseHolder
arr[0] = b; // OK, Beta is subtype of PromiseHolder
a = arr[0]; // OK, PromiseHolder and Alpha are equivalent under 'any'

Was not an error in TypeScript 1.0; is an error now. Appears specific to the use of this in the field initializer in Beta -- this shouldn't change the type inference (due to the explicit generic type parameter), nor should adding a redundant type annotation on the field. Found in internal partner codebase.

[ahejlsberg]

This is by design. It is another case of an initializer witnessing the variable or property it is initializing. Here is a simpler example:

interface A {
    s: string;
}

function foo(x: A): string { return "foo"; }

class C {
    s = foo(this);
}

Here, the new compiler infers any for the s property in C because the initializer witnesses the type of s (specifically, we need to check if C is compatible with A and to do that we need to know the type of s). The old compiler uses some unspecified heuristics to conclude that the type of s is string because that is what foo returns. But it appears to not actually check that C is compatible with A. Even if the definition of A is changed to

interface A {
    s: number;
}

the old compiler still compiles with no error which is just plain wrong.

I don't know of a meaningful way to implement the old semantics (which appear to be wrong in cases) and I believe the new compiler implements this correctly.

[ahejlsberg]

I should add that once we fix #476 we will report an error for self-referencing initializers.

[RyanCavanaugh]

Separately -- how would we expect a user not using noImplicitAny to diagnose this kind of thing?

[ahejlsberg]

Short answer, we wouldn't. The point of inferring any is to not issue errors in cases where inference doesn't succeed (such that we don't break un-annotated JavaScript code). Only when you use -noImplicitAny to opt into the next level of strictness will you see an error.

Sent from my Windows Phone

---

From: Ryan Cavanaughmailto:notifications@github.com
Sent: ý9/ý10/ý2014 7:54 AM
To: Microsoft/TypeScriptmailto:TypeScript@noreply.github.com
Cc: Anders Hejlsbergmailto:andersh@microsoft.com
Subject: Re: [TypeScript] Regression in BCT when type uses 'this' in a member initializer during type inference (#641)

Separately -- how would we expect a user not using noImplicitAny to diagnose this kind of thing?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/641#issuecomment-55127108.