@RyanCavanaugh: this is my take on refreshing the genericDefaults PR. It should resolve the open items you had on#6354 regarding checking defaults against constraints. I also added missing support for typeToString and the declaration emitter. Please let me know if you can suggest any additional tests.

@mhegazy: when we discussed this, I suggested that interface declarations that have defaults must have identical defaults, allowing you to mix declarations with and without defaults:

interfaceX<A,B>{}interfaceX<A,B=number>{}

However, this PR does not reflect that suggestion and is more strict, requiring all declarations to have identical defaults as well. It seems more consistent and we can loosen this restriction at any point if we so choose.

@ahejlsberg: ThegetResolvedDefault function in checker.ts is somewhat similar togetResolvedBaseConstraint. However, I chose to reuse the existingpushTypeResolution/popTypeResolution functions to perform circularity checks. Is there a specific advantage forgetResolvedBaseConstraint to have its own circularity logic? Would you recommend I use that approach forgetResolvedDefault, or would it make sense to modifygetResolvedBaseConstraint to use the type-resolution functions?

@mhegazy: when we discussed this, I suggested that interface declarations that have defaults must have identical defaults, allowing you to mix declarations with and without defaults...
...this PR does not reflect that suggestion and is more strict, requiring all declarations to have identical defaults as well. It seems more consistent and we can loosen this restriction at any point if we so choose.

The latest commit makes the following changes (also noted above):

• If any declaration of an interface or class has a default type for a type parameter, all declarations must have an identical default type.
• A class or interface declaration that merges with an existing class or interface declaration may introduce a default for an existing type parameter.
• A class or interface declaration that merges with an existing class or interface declaration may introduce a new type parameter as long as it specifies a default.

For example:

interfaceX{}// no type parametersinterfaceX<T=never>{}// ok, add a new default type parameterinterfaceY<T>{}// one required type parameterinterfaceY<T=never>{}// ok, make an existing type parameter optionalinterfaceZ{}// no type parametersinterfaceZ<T>{}// error, type parameter lists aren't identical//// uncomment the following to remove the error as the declarations will merge:// interface Z<T = never> { }

@ahejlsberg Per our conversation in the design meeting, I've further modifiedchooseOverload to avoid additional inference overhead when all type arguments are supplied.

Following the discussion during the design meeting, I am making the following changes:

• When specifying type arguments, you are only required to specify type arguments for the required type parameters.Unspecified type parameters can be inferred.Unspecified type parameters will resolve to their default types.

For example:

declarefunctionf<T,U=T>(a:T,b?:U):void;f(1);// ok. Using inference: T is number, U is number.f(1,"a");// ok. Using inference: T is number, U is string.f<number>(1,"a");// error. Not using inference: T is number, U is number.

While this is generally stricter, we can loosen this restriction at a later date if necessary.

I have added the following restriction:

• It is an error to reference a type parameter in a class or interface declaration that is not specified in the declaration, but was introduced in a merged declaration.

This is to provide an error for the following case:

interfaceA{}interface B{x:A;// error}interfaceB<A=number>{}

I have looked into including#13609 in this change, but it results in significant change in behavior that may be too much to take on if we want to take this for 2.2.

@ahejlsberg Do you have any other feedback for this change?

@rbuckton You mentioned taking this for 2.2 in an earlier comment but I see that this issue still has the 2.3 milestone attached. Will this be in 2.2?

@rbuckton You mentioned taking this for 2.2 in an earlier comment but I see that this issue still has the 2.3 milestone attached. Will this be in 2.2?

No. this is scheduled forTS 2.3

Can't wait for this, writing a library in TS and this will save the consumers from a lot of confusion. Great work!