Skip to content
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

Partial type does not accept plain empty object literal as a default #9069

Open
insonifi opened this issue Aug 16, 2023 · 5 comments
Open

Partial type does not accept plain empty object literal as a default #9069

insonifi opened this issue Aug 16, 2023 · 5 comments
Labels
bug Typing: completeness No false positives (type checker claims that there are some errors in the correct program) Typing: destructors

Comments

@insonifi
Copy link

Flow version: 214

Expected behavior

The partial type also accepts object literal as a default value since it is an extreme case where all properties were omitted
<T>(Partial<T> = {}) => {}

Actual behavior

Flow throws an incompatible type error because the object literal is incompatible with {...T}. It can be circumvented by casting an any type to the object.

<T>(Partial<T> = ({}: any)) => {}

Flow try demo

@gkz
Copy link
Member

gkz commented Aug 16, 2023

Technically you can pass in empty as the type argument, and Partial<empty> is empty, and {} is not a valid value for empty

@insonifi
Copy link
Author

The documentation:

This utility converts all of an object or interface's named fields to be optional, while maintaining all the object's other properties (e.g. exactness, variance).

I understand that there could only be an indexed type. Hence empty cannot be used for a partial type.

@gkz
Copy link
Member

gkz commented Aug 16, 2023

empty is a subtype of all types including interface {}

I agree what you are doing is what seems intuitive however

@insonifi
Copy link
Author

What do you think is the idiomatic way to handle it, then?

@gkz
Copy link
Member

gkz commented Aug 16, 2023

There is no way to do that currently. What I'm saying is that what we are currently doing is technically correct and safe, however it obviously doesn't align with what people intuitively think should happen, so we should think about it.

@SamChou19815 SamChou19815 added Typing: completeness No false positives (type checker claims that there are some errors in the correct program) Typing: destructors and removed needs triage labels Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Typing: completeness No false positives (type checker claims that there are some errors in the correct program) Typing: destructors
Projects
None yet
Development

No branches or pull requests

3 participants