Suggestion: Improve generics inference with decorators

[ivogabe]

There have been a lot of users who find it strange that this would compile:

declare function forEach<U>(array: U[], callback: (item: U) => void);
var strings: string[];
var callback: (item: {}) => void;
forEach(strings, callback); // U is inferred as {}

Suggestion: use the decorator @infer to tell the compiler to infer a generic from that argument.
Example:

declare function forEach<U>(@infer<U> array: U[], callback: (item: U) => void);
var strings: string[];
var callback: (item: {}) => void;
forEach(strings, callback); // U is inferred as string (using only the decorated argument), thus this is an error

You can also add @infer to multiple arguments, like this:

declare function forEachOnTwoArrays<U>(@infer<U> firstArray: U[], @infer<U> secondArray: U[], callback: (item: U) => void);

Adding @infer to all parameters would have the same behavior as having no @infer. Adding @infer is optional, thus not a breaking change.

Rules for @infer:

• You may only add type parameters of the direct containing function.
• You can add multiple type parameters like this: @infer<T> @infer<U> (or maybe @infer<T, U>?)
• Generics that are not referenced from an @infer decorator are inferred using the current behavior
• Every generic T that is referenced from an @infer<T> decorator is resolved using all parameters that are decorated with @infer<T> of that function.

Note that this syntax is currently not supported, as the compiler expects ( after the generics. An alternative would be to write it as @infer<U>(), but I think @infer<U> is cleaner.

[danquirk]

My preference is to try to fix type inference in such a way that this sort of manual direction of the system is not required. We talked about this example a bit and think there's actually a pretty simple solution (need to test the full repercussions though).

Are there any other examples where you'd need this facility aside from this case where a generic function takes some number of callbacks whose parameter type is a supertype of an inference site that isn't a function type?

[ivogabe]

Dan Quirk (@danquirk) This case can indeed be fixed by a different algorithm, since U is an input to a callback functions. So it could be possible to stop using function inputs for inference. A different use case, which cannot be fixed using that, is about factory methods. Borrowing from #296:

declare function createElement<P>(type: { new(p: P): React.Component<P> }, props: P): ReactElement<P>;
createElement(MyComponent, propsVariable)

Here P should only be inferred from the first argument. This shouldn't compile:

interface Props { foo: boolean }
class MyComponent<Props> extends React.Component<Props> { }
createElement(MyComponent, { });

I think it's hard to fix this example without adding extra type info.

[fdecampredon]

In fact does not this problem could be easily solved if typescript reintroduced constrain between generics ?
With something like :

declare function createElement<P, U extends P>(type: { new(p: P): React.Component<P> }, props: U): ReactElement<P>;

interface Props { foo: boolean }
class MyComponent<Props> extends React.Component<Props> { }
createElement(MyComponent, { }); // error {} does not extends Props

[ivogabe]

I think this can be closed, as #5949 implements the suggestion of François de Campredon (@fdecampredon).