Relax the rule on the compiler side that all declarations have the same constraint

[mhegazy]

Originally reported in #14840

Consider WeakSet for instance.. today it is defined as interface WeakSet <T> {...}. This is incorrect, as it allows for patterns like const s = new WeakSet<string>(); s.add("foo"); which throws at runtime; the correct definition for WeakSet is interface WeakSet<T extends object> { .. }.

Changing this definition will cause errors in files that redefine WeakSet to add additional members to it.

Error: All declarations of WeakSet must have identical type paramters

The proposal here is to allow type parameter declarations to skip constraints. conflicting constraints should still be reported as errors.

[RyanCavanaugh]

Big fan 👋 👋 👋

[Jessidhia]

Does that mean that, when a constraint is not specified, that it should "inherit" the most specific constraint found elsewhere? Or does that only apply on instantiation?

[mhegazy]

this has nothign to do with instantiations.. it is about declarations..

interface A<T> {}
interface A<T extends number> {}

today this is an error. this issue is to relax the check and treat it as:

interface A<T extends number> {}
interface A<T extends number> {}

Also note that mismatched constraints is still an error:

interface B<T extends number> {}
interface B<T extends string> {}

[RyanCavanaugh]

Easy PR for anyone who wants to take it, or we can pick it up in a bit

[RichiCoder1]

Where would one look to start tackling this?

[ajafff]

@RichiCoder1 there's a function areTypeParametersIdentical in src/compiler/checker.ts:22351
That looks like a good place to start.

[mhegazy]

thanks @HerringtonDarkholme !

[mattmccutchen]

I noticed the behavior is order dependent: it's an error if the first declaration skips the constraint. In fact, mhegazy's example doesn't work. I don't think this is intentional, so I filed a new issue: #23909. It is intentional according to the description of #20883, for better or for worse.