microsoft / microsoft/TypeScript
Allow type narrowing to be specified as always-on or always-off
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 111k
- Forks
- 14.4k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 117
Description
🔍 Search Terms
type narrowing of functions, asserts on getters
✅ Viability Checklist
- 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
⭐ Suggestion
Right now, properties of objects can always be narrowed, whereas functions can never be narrowed. As a developer, I would like to specify when functions can be narrowed, and when object properties can't be narrowed.
📃 Motivating Example
Consider this example:
export const model = {
get value() {
return Math.random() > 0.5 ? 'Hello' : undefined
},
getValue() {
return model.value
}
}
if (model.value) {
console.log(model.value.toLowerCase())
}
if (model.getValue()) {
console.log(model.getValue().toLowerCase())
}
In the TypeScript playground, you can see that even though these code paths are identical in terms of output and function calls, one is narrowed and one is not. TypeScript always assumes that properties are always stable in their values between calls, and assumes that functions are always in-stable in their calls.
You can see this in the TypeScript error which does not error for the property, even though it should.
💻 Use Cases
- What do you want to use this for?
I'm more concerned with the stable function case than the instable property object case. I'm building a Knockout-like observable library that lays on top of Vue. It works fine / perfectly in the Vue ecosystem, however it's TypeScript that doesn't behave here. foo.value is always type-narrowed, whereas foo() is never type-narrowed, even though I can guarantee its stability between calls. Because this behavior in TypeScript is automatic (as far as I know?), there's no way to specify which function calls are stable (and can be narrowed) and which ones are not.
- What shortcomings exist with current approaches?
You can type narrow by assigning the returned value of the function to another variable. However, in Vue, this approach is limited when binding to templates, where v-if will not type-narrow a functional getter.
- What workarounds are you using in the meantime?
A very clumsy workaround is using a Vue computed(), which then also type-narrows.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the TypeScript playground example and reproduce the different narrowing behavior for model.value and model.getValue(). Read the existing type-narrowing behavior, then define and validate an opt-in or opt-out mechanism for stable function calls and object properties; done means the requested cases narrow consistently without changing JavaScript runtime output.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, typescript
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100