Skip to content

Require return type annotation for async functions to be of promise type #5913

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

Closed
wants to merge 1 commit into from

Conversation

cristianoc
Copy link
Collaborator

  • Add annotation@res.returnType to type annotation on the return type of async functions
  • Don't reformat type annotations on the body of async functions
  • Add the type constraint on the return type after promoting the body of async functions

- Add annotation`@res.returnType` to type annotation on the return type of async functions
- Don't reformat type annotations on the body of async functions
- Add the type constraint on the return type after promoting the body of async functions
@ryyppy
Copy link
Member

ryyppy commented Dec 20, 2022

Thanks for the comparison! This helped greatly.

For reference, this is the way async/await does its type annotations rn:

// async function with inline annotations
let someFn = async (num: int): int => {
  num + 1
} 

// async function in an interface declaration
let someFn: int => promise<int>

Following observations from my side, now having both versions at hand:

  • less complexity in the compiler (may not be a justification for the user perspective).
  • less characters to type, and especially since we will often write a lot of boxed types promise<result<int>> it would help with readability.
  • the body and return type declaration are symmetric in case of inline annotations. This is nice, and TS users I've asked would prefer all the short version.
  • The use of promise in an interface type makes sense, since there's no way to use an async keyword neither in a function definition, nor in an external. It also seems easy to document.

@cristianoc
Copy link
Collaborator Author

Closing this as it won't be pursued.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants