Interesting!

I think it is a valid case the rule should warn on, as this example literally narrows down a type from its type constraint to a potentially more specific one.

I initially thought this has to do with type-widening, but it looks like it's related to how type constraints are handled. The rule compares the types (or the type constraints if the compared types have any). Since one type has a type constraint, which is the same as the other type, the validation stops early on. I think a potential solution would be to check the specific types, rather than the type constraints if both type constraints are the same.

Ok, interesting!

So to clarify my understanding of what you said: this behavior is because the rule obtains the expressionType and assertedType using getConstrainedTypeAtLocation, which “will resolve to the type's generic constraint, if it has one” ?

Which means the rule will need to have logic for the special case of generic constraints—because it’s not generally true that A is assignable to B if A’s generic constraint is assignable to B’s (since B “could be instantiated with a different subtype of constraint”)

Huh! We're so used to checking generics' constraints, but, yeah, that might actually be a mistake for this rule.

Might be nice if we can special-case the error message here since the TS error is one that always surprises and confuses me at first when I run into it.

What do you think a better error message would be?

What do you think a better error message would be?

As a first pass, I think we could just model it after the TS error message?

Unsafe type assertion: 'Object' is assignable to the constraint of type 'CustomObjectT', but 'CustomObjectT' could be instantiated with a different subtype of constraint 'Object'.

Doesn't necessarily have to be that, verbatim 🤷... if we get working code that detects this case as the reason for erroring, we could probably bikeshed about wording on the PR.

The only import technical thing here is ensuring that we don't give this error message on a case like

export function myfunc<CustomObjectT extends string>(input: number): CustomObjectT {
  const newCustomObject = input as CustomObjectT;
  return newCustomObject;
}

That snippet is unsafe, but because number is not assignable to string at all, not because of the generic subtypes thing. (Note that it's also a TS error in this case, so it's not super important, but I'm guessing we could come up with a corollary that's not a TS error)

I took a stab at this in #10461—but I really don’t know what I’m doing, so I’d welcome feedback!

The only import technical thing here is ensuring that we don't give this error message on a case like

export function myfunc<CustomObjectT extends string>(input: number): CustomObjectT {
  const newCustomObject = input as CustomObjectT;
  return newCustomObject;
}

I added this example as a test case to ensure we don’t give the “assignable to the constraint” message here!