Default generic type variables

It would be really useful if I could set default values for my generic type variables. In many cases, the users of my class don't want to use a different value and so it's cumbersome to having to type it in.

If I could do this:

class MyClass<T = String>
{
public userData: T;
constructor() {}
}

then the people who don't care about the type of userData (because they don't use it) and the people who are fine with it being a String don't have to set a generic type but others can if they want.

Also, these type variables could default to any or the type they extend (if they do) without explicitly defaulting them.
For example:
<T extends MyClass> would default to MyClass (without explicitly writing it)
and
<T> could default to any

What do you think?

👍 It would greatly simplify definition for some lib, for example something like react components would ideally be :

class Component<P,S,C> {
  props: P;
  state: S;
  context:C
  ....
}

but most of the time S and C are not used, with something like :

class Component<P = {}, S = {}, C = {}> {
  props: P;
  state: S;
  context:C
  ....
}

It would be easy to create simple component that don't use those generic types:

class MyComponent extends Component {
}
// instead of
class MyComponent extends Component<{}, {}, {}>{
}

Interesting idea, though it would seem that this functionality is easily achieved through a subclass.

class Foo<T,U,V> {
    // ...
}

// Or DefaultFoo or BasicFoo
class StringyFoo<U,V> extends Foo<string, U, V> {
    // ...
}

Are there any use cases where doing this becomes annoyingly difficult, or where it doesn't quite achieve the same thing?

François de Campredon (@fdecampredon)

While that could be useful in some cases, I feel I wouldn't use that for these reasons:

it's cumbersome to write new classes just for this
it's inconvenient for the users of my class, ideally they shouldn't have to know that there is a different class written just for the case of having some generic types default to something.

In François de Campredon (@fdecampredon) 's example code with 3 generic variables it would be especially hard to cover all the use cases (some users might want to use just P, others just S, others just C, others P and S, etc..

I'm working on a library right now that could have really benefited from this. When combined with constraints, I'd expect the syntax to look something like the following:

class Component<P extends IProperties = Properties, S = {}, C extends IContext = Context> {
  props: P;
  state: S;
  context: C;
  ....
}

+1. This would be great indeed when working with React.

Btw, why is this labeled under "Needs Proposal" ? This is already present in C++, not in C# unfortunately. However I don't think this would be hard to implement?

why is this labeled under "Needs Proposal" ? This is already present in C++

Someone needs to write down what all the rules for this would be.

For example, would defaults be legal in all generic type parameter positions? If so, what's the behavior in function calls?

declare function f<T = string>(a: T, x: (n: T) => void): void;

// What do we resolve 'T' to here? By what mechanism?
f(null, s => s.charCodeAt(0));

In addition to default type parameter, it would also be great to have named type argument. So I don't need to care about the order.

class Component extends React.Component<P = T1, S = T2> {
}

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) my first (maybe naive) idea for this was a simple preprocessor which would work like this:

for all cases where a generic function / class is used (called / instantiated), and a generic type variable that has a default value is not explicitly set, that default value is injected.

So in the above example, because f is called without given an explicit type it will default to the default generic argument (string) and that's it.
If you change "string" to "number" in the above snippet it will be a compile error because "s" is of type number.

Do you see any problems with this approach? Is it that with a default value we ignore the possibility of type inference that would otherwise work just by looking at the types of the passed function parameters (without setting a generic type)?
Some options are:

ignore type inference when there's a default generic argument (the naive idea)
if type inference would allow to to infer a type, use that type, otherwise use the default type
use the inferred type only if it's "stronger" than the default type (meaning if the inferred type is a subtype of the default type), otherwise use the default type

Let me know if I'm missing something!

Tingan Ho (@tinganho)

Tingan Ho (@tinganho) that sounds like a good idea!

Ryan Cavanaugh (@RyanCavanaugh)

My suggestion would be that type defaulting happens in place of an any type or {} type inference; that is, to expand on Ryan Cavanaugh (@RyanCavanaugh)'s above example:

declare function f<T = string>(a: T, x: (n: T) => void): void;

// 'T' is a string here, because the default overrides the inference of any
f(null, s => { });

// 'T' is a number here due to existing inference
f(15, s => { });

I find it more important on classes, however, where type inference may not be able to be performed.

class MyClass<T = string, U = IMyInterface>
{
    constructor(a: T) { }
}

// 'T' is a number, because it was inferred.
// 'U' is 'IMyInterface', because it was inferred as '{}' by existing logic.
var myVar = new MyClass(15);

// 'T' is a string, because it was inferred as 'any' by existing logic.
// 'U' is 'IMyInterface', because it was inferred as '{}' by existing logic.
var myVar2 = new MyClass(null);

// 'T' is a number, because it was specified.
// 'U' is 'IMyInterface', because it was inferred as '{}'
var myVar3 = new MyClass<number>(null);

// 'T' is a number, because it was specified.
// 'U' is 'string', because it was specified'
var myVar4 = new MyClass<number, string>(null);

As indicated in my example, I'd propose that, just like default (non-type) parameters in function calls, all type parameters after the first defaulted type parameter must have a default.

I'd also suggest that type constraints are evaluated after all inference is complete, in case it matters for constraint checking. (I can't imagine a situation where it would, given type constraints cannot reference type parameters in the same type parameter list at this time.)

I'd rather not discuss named type parameters, as that could be a separate feature entirely. (Open a separate issue, perhaps, Tingan Ho (@tinganho)?)

Matt DeKrey (@mdekrey)

Matt DeKrey (@mdekrey) I agree, it would work well if the default type was only relevant for the {} case.

Is there a use case for specifying both a default and extends? My suggestion would be to not support specifying both, since it might complicate type inference rules.

I suspect that the correct behavior is to defer an application of default generic parameters till the moment when exact count of generic parameters will be determined from the context:

if the context asks less generic parameters -- then leave asked generic parameters open (ignoring possible defaults) and instantiate the rest with the defaults (or report an error if there are no default types specified).

In that case if we have an interface that accepts an unary type constructor

interface X<T<~>> { value: T<number> }

and a binary type constructor with two defaults

interface Y<A = string, B = boolean> { a: A, b: B}

then the application should silently convert binary Y<A,B> to the unary Y<A> = {a:A, b: boolean} by applying the trailing default parameters:

type XY = X<Y>;  /* should be {
     value: {
         a: number, // due to X
         b: boolean // Y's second default parameter
     }
} */

Anatoly Ressin (@Artazor)

Anatoly Ressin (@Artazor) That was my original intuition with my idea.

And to clarify, the query signature for my two examples would be this:

// Using the default parameter
interface KeyDatabase extends Database<KeyPromise> {
    query<T>(s:string, args: any[]): KeyPromise<T>;
}

// Using a specialization (note the unused `T`)
type NumberPromise<T> = KeyPromise<number>;
interface NumberDatabase extends Database<NumberPromise> {
    query<T>(s:string, args: any[]): KeyPromise<number>; // i.e. NumberPromise<T>
}

Blake Embrey (@blakeembrey)

Generic parameter defaults will make the implementation of #1213 and #9949 considerably harder. They seem challenging at presents, so it doesn't help.

Defaults are a source of ambiguities as well. Adding a default may make a function backward incompatible. E.g.

declare function c<A>(f: (x: A) => A, g: (a: A) => A): A;

declare function f<T = number>(x: T): T;
declare function g<T = string>(x: T): T;

c(f, g) // A = string / number or T?

Better type inference and type aliases are more obvious and consistent solutions since defaults help only in the case envisioned by the library/typings author and are opaque to the code maintainers.

The only true benefit of defaults is generifying existing typings (as pointed out by Blake Embrey (@blakeembrey)'s example) but I'd much rather see real generics first..

Marin Marinov (@gcnew)

Marin Marinov (@gcnew)

The only true benefit of defaults is generifying existing typings (as pointed out by Blake Embrey (@blakeembrey)'s example) but I'd much rather see real generics first.

If nested types make it, then this would all of a sudden become far more interesting. You could make a React type namespace, so you could properly type the library, including raw element references, and ensure that React Native-specific components can't be erroneously used in DOM-specific or renderer-independent components. That being simply by using a generic React type instead. It's an extra layer of verification that would allow much more thorough typing.

declare function c<A>(f: (x: A) => A, g: (a: A) => A): A;

declare function f<T = number>(x: T): T;
declare function g<T = string>(x: T): T;

c(f, g) // A = string / number or T?

That would be a good question, though.

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) Are you guys planning to add a milestone to this guy? Looks like you had the spec (and implementation?) mostly fleshed out.

Boris Cherny (@bcherny)

Boris Cherny (@bcherny) work in progress at #13487. I would expect this to be in 2.2 but may slip to 2.3 if we need a few more revisions on the PR.

Ryan Cavanaugh (@RyanCavanaugh)

Awesome, thanks for the excellent work Ryan Cavanaugh (@RyanCavanaugh)!

👍 Thanks. I've been wating a long time.

Navigation Menu

Repository navigation

Default generic type variables #2175

47 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Default generic type variables #2175

Description

Activity

fdecampredon commented on Mar 2, 2015

DanielRosenwasser commented on Mar 2, 2015

andrewvarga commented on Mar 3, 2015

mdekrey commented on Apr 1, 2015

poeschko commented on Jun 26, 2015

andrewvarga commented on Aug 5, 2015

RyanCavanaugh commented on Aug 5, 2015

tinganho commented on Aug 5, 2015

andrewvarga commented on Aug 5, 2015

andrewvarga commented on Aug 5, 2015

mdekrey commented on Aug 6, 2015

Andael commented on Aug 8, 2015

47 remaining items

Artazor commented on Jan 9, 2017

dead-claudia commented on Jan 9, 2017

gcnew commented on Jan 23, 2017

dead-claudia commented on Jan 25, 2017

bcherny commented on Feb 8, 2017

RyanCavanaugh commented on Feb 8, 2017

bcherny commented on Feb 8, 2017

iamssen commented on Feb 16, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions