Suggestion: Generic Parameter Overloads

[omidkrad]

Suggestion moved over from codeplex.

The suggestion is to allow generic parameter overloads like the following:

declare module Backbone {
    class Model{}
    class Events{}
    class ViewOptions<TModel extends Model> {}
    class Collection<TModel extends Model> {}

    // Generic parameter overload
    class View extends View<Backbone.Model>;
    class View<TModel extends Model> extends Events { // Don't take as duplicate identifier
        constructor(options?: ViewOptions<TModel>);
        model: TModel;
        collection: Collection<TModel>;
    }
}

// With Generics Parameter overloads, old non-generic consumer
// code works as before and does not need to change.
class MyView extends Backbone.View {
}
var myView = new MyView();
var model = myView.model; // model is of type Backbone.Model

// Can gradually introduce generic parameters to Views
class DerivedModel extends Backbone.Model { 
}
var myView2 = new Backbone.View<DerivedModel>();
var model2 = myView2.model; // model2 is of type DerivedModel

This is important because this would allow people to introduce generics in their library declarations without breaking large amounts of existing code for the consumers. We do this a lot in C#, and it is compatible with TypeScript design because it won't make any changes in the resulting javascript, and works pretty much like method overloads in TypeScript.

Related discussion: https://typescript.codeplex.com/discussions/452741

[danquirk]

Couple of questions that come out of thinking about this:

1. Would a default value for type parameters in classes not accomplish the same thing? That is:

class View<TModel extends Backbone.Model = Backbone.Model> {
...
}
// currently typed as View, with this feature would be now typed as View<Backbone.Model> 
// because of the default type param value
var v: View;

2. The above leads to the question of whether you'd ever have a default type parameter value other than any or the constraint type. In that case, could the compiler just do this for you and instead of adding complexity to the language with a new piece of syntax it would do something like:

var v: View; // infers View<Backbone.Model> because View had a constraint
var a: Array; // infers Array<any> because Array has no constraint on T

In the past we didn't want to infer any for T which is why we required type parameters for generic types used in type positions. This is mitigated by using --noImplicitAny but it's a little ugly to require that flag to make generics behave well for simple mistakes (ie forgetting to add a type parameter).

[omidkrad]

Yes, both alternatives can do it. I like the second one even better that the compiler figures the type parameter for you. I think that would cover most cases, but just in case, combination of these two also seems to be viable.

[omidkrad]

One case I thought you don't want the compiler to automatically choose the default generic type for you is when you want to keep it to be generic, for example in Collection and ViewOptions below:

class View<TModel extends Model> extends Events {
    constructor(options?: ViewOptions<TModel>);
    model: TModel;
    collection: Collection<TModel>;
}

So it's still good to enforce --noImplicitAny here.

[mikecann]

I dont want to be the "Me Too" guy but this is definitely needed for a signals library im using!

class Signal {
    }

    class Signal<T> {
    }

    class Signal<T,U> {
    }

    class Signal<T, U, V> {
    }

[johnnyreilly]

👍

[sccolbert]

👍

[omidkrad]

Glad this is still being considered. This feature can be taken as two things:

1. Generic Parameter Overloads, where same class name can get multiple definitions with different number of generic type parameters.
2. Default value for generic type parameters, as @danquirk said.

The first one can cover use cases for the second one, but the opposite is not true. If true C#-like Generic Parameter Overloads is supported where each overload defines its own implementation, then the compiler has to give a different name to each overload in the generated JS. For example, View, View_$1, View_$2, etc. which can make it more complex. This feature is going to be nice, but I think allowing default value for generic type parameters is more needed, and would make zero footprint in the generated JS.

[RonPenton]

Any movement on this one? I've run into the situation where I want to do this:

    export interface Func<R> { (): R; }
    export interface Func<P, R> { (parameter: P): R; }
    export interface Func<P1, P2, R> { (parameter1: P1, parameter2: P2): R; }
    export interface Func<P1, P2, P3, R> { (parameter1: P1, parameter2: P2, parameter3: P3): R; }
    export interface Func<P1, P2, P3, P4, R> { (parameter1: P1, parameter2: P2, parameter3: P3, parameter4: P4): R; }

But Instead I have to define them like this:

    export interface Func0<R> { (): R; }
    export interface Func1<P, R> { (parameter: P): R; }
    export interface Func2<P1, P2, R> { (parameter1: P1, parameter2: P2): R; }
    export interface Func3<P1, P2, P3, R> { (parameter1: P1, parameter2: P2, parameter3: P3): R; }
    export interface Func4<P1, P2, P3, P4, R> { (parameter1: P1, parameter2: P2, parameter3: P3, parameter4: P4): R; }

It's not the end of the world, but it is pretty annoying.