-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
As-is, it is impossible to accurately refine types in a generic context #17
Comments
This is already solved in |
That's less than 0.1% and almost all 6.1k results comes from big libraries like |
|
Related to #30 |
The type The correct type is |
Anyway, @DScheglov is right about the inability to discriminate in a generic context with that type. |
This makes it impossible to refine the type in a generic function
T
andE
can containnull
, it is impossible to determine whether the result is in the "error" or "ok" case. There are no such problems with a discriminated union.[T, null] | [null, E]
, which is backwards. I won't fix that, because that's indicative of the fact that ordering is a footgun here, which is solved by using a discriminated union.T
andE
, which is to say, pretty much every single API.Result<T, Exclude<E, null>>
, but I couldn't get it to work. But let's assume that something like this does work! That means that this constraint will propagate itself everywhere.One response: you should never throw null.
throw null
a common pattern? Not directly. 6.1k results on GitHub. This is likely to be much more common than this indicates, however, due to code that accidentally throws null, such asthrow lookUpUserReadableErrorMessage(e)
.throw null
a bad pattern? Not necessarily. If your error case contains no information, it only hurts performance to allocate objects, though one could conceivablythrow true
or something.But a discriminated union also allocates an object
Conclusion
The text was updated successfully, but these errors were encountered: