Parameter signatures of functions in object literals are not always inferred correctly.

[rjamesnw]

Hi, I ran into an issue where the types don't seem to be inferred correctly. Consider this:

interface ITestHandler { (a: string, ...args: any[]) }
interface ITestHandlers { [index: string]: ITestHandler; }
class Test { Events: ITestHandlers; }
var t = new Test();
t.Events = {
     handler1: (a) => { }, // <= this works fine, 'a' is 'string'
     handler2: (a, b: string) => { } // <= 'a' is 'any', but 'b' is optional in the interface!
};

I expect "a" for "handler2" to be "string", but instead it is "any". Shouldn't "a" be interred from the signature, since the "args" are of type "any", which should match any type?

Thanks.

[DanielRosenwasser]

This is actual per spec. From section 4.10 Function Expressions:

When a function expression with no type parameters and no parameter type annotations is contextually typed (section 4.23) by a type T and a contextual signature S can be extracted from T, the function expression is processed as if it had explicitly specified parameter type annotations as they exist in S.

The rule is effectively that a function expression isn't contextually typed if it has any type annotations on its parameters.

[rjamesnw]

Just because it says that in the spec doesn't mean that it makes any sense. The compiler should infer missing types at the same positions when a type is missing on the function expression. Just doesn't make any sense really. At the very least, it should see the given parameter type "string" as compatible with "any" and continue to infer the other types (especially if the given parameter type is optional!). It's really annoying to have a list of functions on an object all of the same supporting signatures, and for some, having to explicitly specify the missing parameter types that don't infer.

Bottom line, since b is optional (based on the interface signature), and has a type that can be assigned to the optional parameters, the missing type(s) should infer (in fact, with "no implicit any", I'm sure it would err out in the case above).

[zpdDG4gta8XKpMCd]

wow...

guys, you keep making people really pissed off with all your specs and the way you do you work, you need to double your effort and stop letting good developers down, jeez..

[JsonFreeman]

I believe the rationale here is that you either want the function's entire parameter list explicitly typed, or the entire parameter list inferred. It has been spec'd this way because the thinking was, if the user put a type annotation on any parameter, it means the user wants the type system to back off and let them do the typing.

In this case, it looks like the intent of the contextual signature was to be exact/specific about the type of one parameter, and vague about others (in this case the rest). Then when contextually typing a function expression, the specific type should be automatically assigned to the corresponding parameter in the function expression, but the "vague type" should be overridden by the explicit type annotation in the function expression.

The compiler would need some way to know whether the explicit type annotations in the function expression correspond to positions of "vague types" in the contextual signature. If so, the remaining parameters should have their types assigned by contextual typing. If not, then it is a signal that the user wants these remaining parameters to be of type any. Is there any meaningful heuristic for whether a parameter in the contextual signature is "vague"?

[rjamesnw]

Sounds about right. I expected that if a parameter type of a function expression in context is missing, and the other parameters are of a same or super type (or 'any') to the expected signature in the context, that it is quite obvious the developer wants the missing parameter types inferred.

[DanielRosenwasser]

@Aleksey-Bykov @rjamesnw my apologies. When I said it's in the spec, I didn't mean to shoot you down - that's why I didn't close the issue as "by design". I mostly wanted to just give context that this isn't a compiler bug, but rather, a potential improvement for the language.

I didn't realize this was the case either, and indeed, I expected the un-annotated parameters to be contextually typed as well.

[JsonFreeman]

It would be a breaking change though, if we suddenly contextually typed all missing parameters. It's just a question of how many partially annotated contextually type-able parameter lists there are out there.

[rjamesnw]

Only for those not using "no implicit any". ;) And even then, it would be of type "any", so I'm guessing it wouldn't break much. In fact, it'll probably help people find bugs and push them to add proper types for the rare cases. I think there are more benefits than not.

[zpdDG4gta8XKpMCd]

@DanielRosenwasser I was kidding when I said that (wasn't too funny I know), but @rjamesnw seemed seriously upset

[rjamesnw]

Annoyed, but not upset, lol. ;)

[DanielRosenwasser]

It'd be a breaking change, but the workaround would be casting the function to any, so I don't think it would be terrible.

@Aleksey-Bykov tone sometimes doesn't transfer online all that well, but I can sorta see it now - @rjamesnw awesome, as long as you're not upset! 😄