Skip to content

Infer return type of function based on safe guard #40802

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
5 tasks done
Fuzzyma opened this issue Sep 28, 2020 · 3 comments
Closed
5 tasks done

Infer return type of function based on safe guard #40802

Fuzzyma opened this issue Sep 28, 2020 · 3 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@Fuzzyma
Copy link

Fuzzyma commented Sep 28, 2020

Search Terms

return type, typeguard, infer type

Suggestion

Typescript should be able to infer the correct return type of a function based on its input + type guards:

function foo(arg: number[] | number) {
    if (Array.isArray(arg)) { // typeguard
        return [1] // arg is an array, so return is clear to be an array as well
    }

    return 0 // arg is a number, return type should be 0
}

At the moment the return type is always number[] | 0 so you cant use any array or number specific methods on the result

Use Cases

I am a fan of letting typescript do its job and let it infer as much as possible. In this special case, it either prevents me from writing explicit overloads or from using generics. It is just very convenient

Examples

foo([]).push(5) // no error
foo(5).toFixed(2) // no error

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, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

PS: I asked about this on stackoverflow here. The answer was that it might be possible but probably too cost intensive. However, I would like to have a second opinion here

@jcalz
Copy link
Contributor

jcalz commented Sep 28, 2020

Duplicate of or related to #17747.

It would definitely be a lot more work for the compiler to synthesize a conditional generic signature or set of overloaded signatures. Even without performance considerations, most of the time you wouldn't want this to happen, since the compiler would most likely produce the most complicated mess that exposes the full details of the implementation to callers.

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Sep 28, 2020
@RyanCavanaugh
Copy link
Member

There is a very fine line here between "providing good inference" and "reciting the function implementation as the return type". That the array return value corresponded to the array input may entirely be an implementation detail, or may be part of the public contract of the function, and it's really unclear how you would draw the distinction in a way that was intuitive and predictable. Absent other evidence, our stance is that functions aren't instrinsically trying to expose their exact implementations to their callers, so we don't perform this kind of inference.

@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants