> This statement makes me think... how come the TS compiler is not using something like a hash/map (object) of union members to basically ignore redundancy?
The trouble is the operation isn't "is X a member of Y", rather it's "does X match any values of Y according to predicate P."
You can break that out if you have knowledge of possible X's and P, as is the case with type matching.
Say we are checking G[] against {str, "foo literal", int[]}. I have no idea how TS implements these internally, but say the underlying type expressions are:
You'd still have to try to match that generic parameter against all the possible Arrays, but you could add more levels of hashing.
The downside is, of course, it's quite tricky to group types like this and prove that it returns the same results as checking all pairs, especially when you have a complex type system.
The trouble is the operation isn't "is X a member of Y", rather it's "does X match any values of Y according to predicate P."
You can break that out if you have knowledge of possible X's and P, as is the case with type matching.
Say we are checking G[] against {str, "foo literal", int[]}. I have no idea how TS implements these internally, but say the underlying type expressions are:
And G[] is {head:Array, element: {head: Generic, name: "G"}}.We could reasonably require that heads are all simple values, and then group types as such:
You'd still have to try to match that generic parameter against all the possible Arrays, but you could add more levels of hashing.The downside is, of course, it's quite tricky to group types like this and prove that it returns the same results as checking all pairs, especially when you have a complex type system.