You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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)
The text was updated successfully, but these errors were encountered:
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.
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
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
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:
which should have been
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:
The text was updated successfully, but these errors were encountered: