New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Types .. have no overlap" (2367) error when LHS and RHS generics both extend same constraint #51584
Comments
This is always going to be true, since all types overlap at |
Hmm, this seems like a duplicate of #50893 which is tagged as a bug. @RyanCavanaugh, thoughts? |
The difference is between |
Agreed, but that's materially different to this case where we have two types that are related by a common constraint, isn't it? I guess I can't see a reason for this error in cases where the common supertype is known to be neither Let me give you an example that's closer to my actual code: enum Model { User, Group }
interface User { name: string, group: Group }
interface Group { name: string }
type RecordType = {
[Model.User]: User;
[Model.Group]: Group;
}
class View<T extends Model> {
constructor(
readonly primaryModel: T
) {}
consume<U extends Model>(model: U, record: RecordType[U]) {
if (model === this.primaryModel) { // <-- error
this.consumePrimaryModel(record);
}
else {
this.consumeForeignModel(record);
}
}
consumePrimaryModel(record: RecordType[T]) {}
consumeForeignModel(record: RecordType[Model]) {}
} A As written, the code feels correct, but doesn't type-check without additional assertions, which feels clunky (and IMO less safe, since it's possible to get the type assertion wrong). |
Not really. Even "unconstrained" type parameters are implicitly constrained by |
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
Bug Report
π Search Terms
2367 types overlap
π Version & Regression Information
β― Playground Link
Playground link with relevant code
π» Code
π Actual behavior
An error is raised on the
if
clause.π Expected behavior
Both
U
andT
are constrained byBase
, so they conceivably could overlap, so comparing them should be OK (and as a side-effect, it'd be nice if the comparison also refinedU
toT
inside theif
block).maybe related: #50893 (PR: #50978)
The text was updated successfully, but these errors were encountered: