Strange this parameter behaviour

[olmobrutall]

TypeScript Version: 2.0.0 beta with "noImplicitThis": true

Code

interface String {
     contains(this: string, str: string): boolean;
}

 // OK
String.prototype.contains = function (this: string, str: string): boolean { 
    return this.indexOf(element) != -1;
};

//Error: 'this' implicitly has type 'any' because it does not have a type annotation.   
String.prototype.contains = function (str: string) {
    return this.indexOf(str) != -1;
};

// OK
String.prototype.contains = function (str): boolean { 
    return this.indexOf(str) != -1;
};

// OK
String.prototype.contains = function (str) { 
    return this.indexOf(str) != -1;
};

Look like once you type some parameters you have to type all of them, including the this.

What's the reason?

[mhegazy]

//cc @sandersn

[sandersn]

The problem is that it's confusing when contextual typing applies or doesn't apply. Let's look at your examples in order:

1. Typed parameter, explicit this

   String.prototype.contains = function (this: string, str: string) ...

   This is OK because you explicitly give this a type. No contextual typing happens here.

2. Typed parameter, no this

   String.prototype.contains = function (str: string) ...

   This is not OK because you give str a type. This disables contextual typing, meaning that this doesn't get the contextual type from your String definition. So it becomes any, which triggers --noImplicitThis.

3. Untyped parameter, explicit return

   String.prototype.contains = function(str) ...

   This is OK because str doesn't have a type. Contextual typing works now, and pulls in string for the type of str as well as string for the type of this.

4. Untyped parameter, no return

   This is the same as (3). Return types do not affect whether a function expression is contextually typed.

Overall, the system is behaving as expected. I'd recommend dropping all type annotations and letting contextual typing and return type inference take care of it. However, the existing string methods should also have this annotated, just like your polyfill. I'll create a separate issue for that.

[mhegazy]

#4241 is tracking changing this behavior so that one argument type annotation does not block inference for the rest unannotated ones.