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

Allow declaring that a function return value must be assigned #25794

Closed
4 tasks done
OliverUv opened this issue Jul 19, 2018 · 3 comments
Closed
4 tasks done

Allow declaring that a function return value must be assigned #25794

OliverUv opened this issue Jul 19, 2018 · 3 comments
Labels
Duplicate An existing issue was already created

Comments

@OliverUv
Copy link

Search Terms

ensure return value
must return value
require return value
must assign return value
must use return value
ensure assign return value
ensure use return value
require assign return value
require use return value

Suggestion

I wish to state in a function type declaration, that any caller of this function must assign the return value to a variable. The intention is that the return value may contain error information, and should be either used, or consciously ignored. I want to avoid situations where someone forgets to check a return value.

I am essentially proposing that TypeScript support the same functionality that was recently accepted into Rust: https://github.com/rust-lang/rfcs/blob/master/text/1940-must-use-functions.md

I do not have a specific suggestion for the syntax to be used. Perhaps a built in function decorator could be used.

Use Cases

  • Functions which may return error values which should be checked
  • Functions which return handles to Pooled Objects for which some reference should always be alive
  • Functions which return intermediate values in a chain of function calls, which would leave a component in an invalid state if the intermediate value isn't used

Examples

Just today I forgot to check some return values returned by an API that I wrote a few weeks ago. Essentially something like this:

manager.create_entity('boss', 'Biggie Baddie');

which should have been

const res = manager.create_entity('boss', 'Biggie Baddie');
if (r.is_error(res)) {
  // handle error
}

I do not want to rely on catch/throw here, because manager is part of a separate library that has other semantics for propagating errors. This error is not fatal, but it is one that should always be responded to, especially in dev environments where misspelled Entity type names should be encountered at first.

For this example, I am using resul-ts for the Result/Either-like return type.

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript / JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. new expression-level syntax)
@ghost ghost added the Suggestion An idea for TypeScript label Jul 19, 2018
@ghost
Copy link

ghost commented Jul 19, 2018

It might be possible to write a lint rule for this: at each ExpressionStatement containing a CallExpression (or TaggedTemplateExpression or JsxElement or JsxSelfClosingElement), check if the function called is marked with a /** @mustUseResult */ jsdoc tag.

@mhegazy
Copy link
Contributor

mhegazy commented Jul 19, 2018

Duplicate of #8584, #17282, and #8240

@mhegazy mhegazy added Duplicate An existing issue was already created and removed Suggestion An idea for TypeScript labels Jul 19, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants