Allow type parameter constraints to reference other type parameters

[NN---]

I would like to have some feature that infers any possible types from the given object in the generic function.
For instance I have a function that receives Object, and I want to have a more specific callback than 'any'.
Current code:

function a(obj: Object, f: (value: any) => any) {
 for(var p in obj) if(obj.hasOwnProperty(p)) {
 (<any>obj)[p] = f((<any>obj)[p]) 
 }
}

a({x:1}, (value: any) => (<number>value)+1);

I wish I had something with more strict typing.

function a<T extends Object, Value: union_of_properties_types_of(T)>(obj: T, f: (value: Value) => Value) {
 for(var p in obj) if(obj.hasOwnProperty(p)) {
 (<any>obj)[p] = f(<Value>(<any>obj)[p]) 
 }
}

// 'f' is denoted to number => number
a({x:1}, value => value+1);

// 'f' is string => string
a({x:"x", y:"y"}, value => {
 return value+"z";
});

[danquirk]

If we allowed type parameter constraints to reference other type parameters this signature might get you what you wanted:

function a<PropType, T extends { [idx:string]: PropType }>(obj: T, f: (value: PropType) => PropType) { .. }

[NN---]

If PropType will be a union type, then yes.

[jbrantly]

I wanted to give another example for where this would come in useful in the React bindings.

React has an API that looks like createElement(componentType, props). The type of props is specific to the componentType being used. Today this is modeled with:

createElement<P>(type: { new(): Component<P> }, props: P): ReactElement<P>

However, in actuality there is an implicit prop called ref that can be used on any component. This prop is a function whose single argument is an instance of the component. This could be modeled with:

createElement<P, C extends Component<P>>(type: { new(): C }, props: P & { ref: (component: C) => any }): ReactElement<P>

However, the above isn't currently allowed due to this issue. Ideally not only would the above be allowed but also have the type arguments inferred from usage.

[RyanCavanaugh]

Anders Hejlsberg (@ahejlsberg) is going to see what would be involved in removing the restriction. It may be as simple as removing the error, or there may be deeper problems with circularity that motivated this back in the Ye Olde Compiler days.

[DeadMG]

I would really like this as well for strongly typing a function that can merge properties, e.g. _.extends. The intersection syntax can correctly tell the compiler the return type of the function, but it can't infer types for the properties of the arguments that also exist on T. Having T extend U would be sufficient I think. React's setState is another example of a function that merges two objects that can't really be properly typed- the only solution we have so far is to make every property optional and then take T.