Report better errors on return expressions for immediately-assigned functions
See original GitHub issueSuggestion
š Search Terms
return type label:"Domain: Error Messages"
ā Viability 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. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This feature would agree with the rest of TypeScriptās Design Goals.
ā Suggestion
Error reporting for mismatches between a functions return type and what is being returned by a particular return
statement should be consistently reported a the location of the offending return
.
š Motivating Example
type Foo = (input: string) => number;
const foo: Foo = (input) => {
switch (input) {
case "1":
return 1;
case "2":
return "2";
default:
return Infinity;
}
}
The following error is reported on the declaration of foo
.
const foo: Foo
Type '(input: string) => number | "2"' is not assignable to type 'Foo'.
Type 'number | "2"' is not assignable to type 'number'.
Type 'string' is not assignable to type 'number'.(2322)
const bar = (input: string): number => {
switch (input) {
case "1":
return 1;
case "2":
return "2";
default:
return Infinity;
}
}
The following error is reported on return "2"
:
Type 'string' is not assignable to type 'number'.(2322)
š» Use Cases
In the second example itās much easier to see where the problem is. In larger functions for more `returns it can be even hard to pin down which one is causing the issue. These two examples are very similar and I would expect the same error to be reported for each.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:6 (5 by maintainers)
Top Results From Across the Web
Recoverable Errors with Result - The Rust Programming ...
Let's call a function that returns a Result value because the function could fail. In Listing 9-3 we try to open a file....
Read more >Warning: unreachable code after return statement - JavaScript
When an expression exists after a valid return statement, a warning is given to indicate that the code after the return statement is...
Read more >Exceptions and debugging - Advanced R. - Hadley Wickham
This chapter will teach you how to fix unanticipated problems (debugging), show you how functions can communicate problems and how you can take...
Read more >Common issues and solutions - mypy 0.991 documentation
There are several common reasons why obviously wrong code is not flagged as an error. The function containing the error is not annotated....
Read more >Examples of expressions - Microsoft Support
An expression is a combination of mathematical or logical operators, constants, functions, table fields, controls, and properties that evaluatesĀ ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I donāt think we would ever get rid of the error where itās placed in the first example. The fundamental assignability check there is the whole function to
Foo
, whereas in the latter, the assignability check is the return type tonumber
. I would argue that being able to follow the logic of these comparisons is an acquired skill, but is actually useful and important to users as they try to work out increasingly complicated errors. However, I totally agree that once the error elaboration gets down to the"2"
comparison, it can be hard to find what itās talking about if the function is any bigger. It seems like there might be a good opportunity for a related error span here. /cc @DanielRosenwasser, as error reporting is his favorite topic.Yeah, when to report what kind of error can be pretty contextual. Explicitly including the return value even when using the
Foo
type gives me the behavior I want in this case. Itās a little extra typing so not a big deal.