any inferred as type parameter even with --noImplicitAny

[ghost]

TypeScript Version: nightly (2.1.0-dev.20161002)

Code

function second<T>(tuple: [any, T]): T
function second<T>(tuple: [any, T, any]): T
function second(tuple: any[]): any {
    return tuple[1]
}

function segundo<T>(tuple: [any, T] | [any, T, any]): T {
    return tuple[1]
}

const pairs: [number, string][] = [[1, "two"]]
const x: number[] = pairs.map(second)
const y: number[] = pairs.map(segundo)

Expected behavior:

Both x and y are compile errors.

Actual behavior:

y fails with:

a.ts(13,7): error TS2322: Type 'string[]' is not assignable to type 'number[]'.
  Type 'string' is not assignable to type 'number'.

but x does not fail, because the generic parameter of map is inferred as any rather than string, even with --noImplicitAny turned on.

On another note, I'm not sure what's happening below: either the type parameter of identity is inferred as any or it's inferred as string & number and function bivariance wreaks its magic:

function useStringToNumber(f: (s: string) => number): void {}
function identity<T>(t: T): T {
    return t
}
useStringToNumber(identity)

[sergey-shandar]

Related issue #3038

[mhegazy]

looks like a duplicate of #11152

[ghost]

Here's a simpler example:

declare function f<T>(x: T): T;
declare function f<T>(x: T, y: number): T;

const a: string[] = ["a", "b"];
const b = a.map(f);

Even in the absence of a type annotation on b, I would still expect to get either a compile error or a type other than any[].

[mhegazy]

looks like the same issue as #9366

[mhegazy]

The last example is technically as spec'ed. see 4.15.2 Type Argument Inference:

If e is an expression of a function type that contains exactly one generic call signature and no other members, and T is a function type with exactly one non-generic call signature and no other members, then any inferences made for type parameters referenced by the parameters of T's call signature are fixed, and e's type is changed to a function type with e's call signature instantiated in the context of T's call signature (section 3.11.6).

[mhegazy]

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