Don't mention constraints in errors when type parameters don't explicitly specify them

[DanielRosenwasser]

function f<T>(x: T) {
    x = {};
}

Current

Type '{}' is not assignable to type 'T'.
  '{}' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint '{}'.

Type '10' is not assignable to type 'T'.
  '10' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint '{}'.

Nobody ever mentioned a constraint or {} in this code, so why is it being displayed? As a user, this is telling me more than I needed or wanted to know.

Proposed

Type '{}' is not assignable to type 'T'.
  'T' could be instantiated with an arbitrary type which could be unrelated to '{}'.


Type '10' is not assignable to type 'T'.
  'T' could be instantiated with an arbitrary type which could be unrelated to '10'.

[dagda1]

I see the same error in this playground. I am at a loss to what the error is and where {} is coming from

[jack-williams]

Looks like the default constraint is coming through as {}, but shouldn't it be unknown now?

[dagda1]

i’m seeing this in many places in many different projects

[dagda1]

i have no idea what the error message means

[fatcerberus]

Looks like the default constraint is coming through as {}, but shouldn't it be unknown now?

I had the same question. It was changed to unknown in TS 3.5 but still shown as {} in (some? all?) relevant error messages.

[jack-williams]

I debugged this and the summary is that noConstraintType is defined as an empty object type.

const noConstraintType = createAnonymousType(undefined, emptySymbols, emptyArray, emptyArray, undefined, undefined);

Changing this type to be defined as unknown changes the error message accordingly.

PR: #33445

[jack-williams]

On the topic of error messages: A proposal:

• 'T' could be instantiated with a type that is unrelated to '10'.,
• or, just specify no additional elaboration.

[jack-williams]

@dagda1 Sorry, to answer you questions.

Assigning a concrete type to a generic type parameter is incorrect because the type parameter can always be instantiated to some arbitrary type:

function f<T>(x: T) {
    x = {};
}
f(3);
f(true);
f("something else");

In the body of the function you have no control over the instantiation by the calling context, so we have to treat things of type T as opaque boxes and say you can't assign to it.

A common mistake or misunderstanding was to constraint a type parameter and then assign to its constraint, for example:

function f<T extends boolean>(x: T) {
    x = true;
}
f<false>(false);

This is still incorrect because the constraint only restricts the upper bound, it does not tell you how precise T may really be.

To try and address this misunderstanding the additional error elaboration was provided, but in the most degenerate case, an unconstrained parameter, the elaboration is really just noise.

The {} you see is the implicit constraint on the type paramater.

[dagda1]

@jack-williams thank you for the explanation although I see this error a crazy amount of times now and the implicit {} constrain is what I always see.

The example in this playground on line 34 has nothing to do with assigning to a constraint and I would really appreciate an explanation of what the error message is trying to tell me here.

I have so many other examples.

[jack-williams]

Line 34 is trying to assign A | B | null | undefined to B | null | undefined which fails because A is not related to any union constituent in B | null | undefined. Type parameter A does not have an explicit constraint which is why you see the additional spurious message; the error message is using the implicit constraint when it should not be and that should be getting fixed.

The error message is correct though, and symptomatic of the fact that nullableFunctor does not satisfy the functor laws. For the correct typing you need negation types and to constraint A to not (null | undefined).