-
Notifications
You must be signed in to change notification settings - Fork 122
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
Object.entries/Object.values – values inference on second overload #95
Comments
Inference for Object.values looks fine to me! |
I guess I should've been more specific with the use case. |
Aha, didn't see that sneaky second overload there. Yes, that's definitely worthy of our attention. |
mattpocock
changed the title
Object.entries/Object.values – values inference
Object.entries/Object.values – values inference on second overload
Mar 4, 2023
Whoops, this is a duplicate of #78 |
@mattpocock I initially posted on that issue XD |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey @mattpocock,
I see your reasoning under not adding
Object.entries
and from my understanding it's connected to the keys on an object.But what about values?
TS defines values there as
any
so it feels unsafe.Object.entries(o: {}): [string, any][];
Object.values(o: {}): any[];
I'm not sure if
ts-reset
should infer values or we should leave it asunknown
.In case I'm using zod when I receive data and then do some operations on it I'd prefer to have inference.
The text was updated successfully, but these errors were encountered: