You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In cases with discriminant unions that don't fit the conventional form (e.g. one property that's constant among all union members) type discrimination doesn't happen as one might expect or desire, see the code example.
I tried to search to see if this had been talked about before, but couldn't find anything. I imagine the current design was around capturing a common pattern in js while not spending too much time trying to narrow the types.
To address this in the same framework: discriminateTypeByDiscriminableItems and isDiscriminantProperty would have to be tweaked to handle missing properties and it's not clear how that would work with exactOptionalPropertyTypes. Alternatively, the existing code may work by first filtering the union down to feasible assignments based on the exitance of properties, e.g. only consider types that the object literal has every non-optional property. However, doing that correctly would require constructing a filtered union type and I'm not sure if there's precedent for that.
Doing any of this will likely cause a performance penalty, so I think it's also fair to say this pattern is infrequent enough to not care about getting correct.
🔎 Search Terms
discriminant unions narrowing
🕗 Version & Regression Information
This is the behavior in every version I tried, and I reviewed the FAQ for entries about 3.3
Whether f invokes this function with a string or number is not predictable based on the types. If you "block out" the other discriminants to prevent that from happening, this works as hoped:
I understand they're not sealed, but as written, the object literal
{
b: true,
cb: n => n.toFixed()
}
is not assignable to DiscriminatorA. I'm not saying it should generally reject one or the other, I'm saying when called with a literal, it should be able to infer the function type in these cases.
Overall I think your assessment of trade-offs is correct -- this pattern doesn't really work outside this immediate example and isn't worth spending cycles on
In the example above, the current behavior seems correct, you can't narrow the type in the union. Whether you would then infer something about the unknown property seems like a different issue.
There are some potential cases where this comes up due to not having a discriminable member e.g. this playground, and more so came up in picking optional properties in the same context (#48448). But given your assessment, I'm cool with closing until/if there's an actual use-case that justifies it.
Bug Report
In cases with discriminant unions that don't fit the conventional form (e.g. one property that's constant among all union members) type discrimination doesn't happen as one might expect or desire, see the code example.
I tried to search to see if this had been talked about before, but couldn't find anything. I imagine the current design was around capturing a common pattern in js while not spending too much time trying to narrow the types.
To address this in the same framework:
discriminateTypeByDiscriminableItems
andisDiscriminantProperty
would have to be tweaked to handle missing properties and it's not clear how that would work withexactOptionalPropertyTypes
. Alternatively, the existing code may work by first filtering the union down to feasible assignments based on the exitance of properties, e.g. only consider types that the object literal has every non-optional property. However, doing that correctly would require constructing a filtered union type and I'm not sure if there's precedent for that.Doing any of this will likely cause a performance penalty, so I think it's also fair to say this pattern is infrequent enough to not care about getting correct.
🔎 Search Terms
discriminant unions narrowing
🕗 Version & Regression Information
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
Parameter 'n' implicitly has an 'any' type.(7006)
🙂 Expected behavior
type checks successfully
The text was updated successfully, but these errors were encountered: