Description
Suggestion
🔍 Search Terms
return type contextual typing
✅ 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 + Motivating Example
I think this is a feature request rather than a bug report, but I'm not sure... I know that contextual typing is currently applied selectively, and that that's intentional, but I couldn't find many issues discussing what the boundaries for applying contextual typing are intended to be. I also don't know what real-world code would've motivated the current rules, so it's possible that my suggestion here would be helpful for the example case below but be counterproductive overall.
Anyway, here's the code I'm dealing with (simplified):
abstract class Item {
abstract get categories(): Category[];
}
class Book extends Item {
get categories() {
return [{
label: 'Sports',
children: [
{ label: 'Baseball', children: [] },
{ label: 'Tennis', children: [] }
],
}];
}
}
type Category = ParentCategory | LeafCategory;
type ParentCategory = {
label: string;
children: [Category, ...Category[]];
};
type LeafCategory = {
label: "Baseball" | "Tennis";
children: [];
};In this code, I'd expect the Book.categories getter to type check, but it doesn't.
The expression being returned is assignable to Category[] if Category[] is used to contextually type it — i.e., the code works if I add satisfies Category[] at the end of the returned expression, or if I do const x: Category[] = /* same expression */; return x;.
However, without contextual typing, TS infers an array type (i.e., { label: string; children: never[]; }[]) as the type for the outermost children property, whereas ParentCategory requires that be a tuple type, to enforce that the array is non-empty.
So, my suggestion/feature request would to apply contextual typing in (at least) the case above (if it's not already supposed to apply there) — but again, I'm not sure what downsides this might have for other code.