Fixes#33912.
Fixes#33014.

Motivation

Sometimes we want to write functions whose return type is picked between different options, depending on the type of a parameter. For instance:

declareconstrecord:Record<string,string>;declareconstarray:string[];functiongetObject(group){if(group===undefined){returnrecord;}returnarray;}constarrayResult=getObject("group");constrecordResult=getObject(undefined);

If we want to precisely express this dependency between the return type and the type ofnameOrId, we have a few options.
The first one is to use overloads:

declareconstrecord:Record<string,string[]>;declareconstarray:string[];functiongetObject(group:undefined):Record<string,string[]>;functiongetObject(group:string):string[];functiongetObject(group:string|undefined):string[]|Record<string,string[]>;functiongetObject(group:string|undefined):string[]|Record<string,string[]>{if(group===undefined){returnrecord;}returnarray;}constarrayResult=getObject("group");constrecordResult=getObject(undefined);

However, if you make a mistake in the implementation of the function and return the wrong type, TypeScript will not warn you. For instance, if instead you implement the function like this:

declareconstrecord:Record<string,string[]>;declareconstarray:string[];functiongetObject(group:undefined):Record<string,string[]>;functiongetObject(group:string):string[];functiongetObject(group:string|undefined):string[]|Record<string,string[]>;functiongetObject(group:string|undefined):string[]|Record<string,string[]>{if(!group){// An empty string is falsyreturnrecord;}returnarray;}constbadResult=getObject("");// Type says this returns `string[]`, but actually it returns a record.

then your function implementation doesn't respect the overload signatures, but TypeScript will not error.

The alternative to overloads is to use conditional types, like so:

declareconstrecord:Record<string,string[]>;declareconstarray:string[];functiongetObject<Textendsstring|undefined>(group:T):Textendsstring ?string[] :Textendsundefined ?Record<string,string[]> :never{if(group===undefined){returnrecord;// Error! Type 'Record<string, string[]>' is not assignable to type 'T extends string ? string[] : T extends undefined ? Record<string, string[]> : never'.}returnarray;// Error! Type 'string[]' is not assignable to type 'T extends string ? string[] : T extends undefined ? Record<string, string[]> : never'}constarrayResult=getObject("group");constrecordResult=getObject(undefined);

However, while everything works out for the callers ofgetObject, in the implementation TypeScript errors on the return statements, because it compares the type of the return expression to the annotated conditional return type, andRecord<string, string[]> is not assignable toT extends undefined ? Record<string, string[]> : never.

Solution: conditional return type narrowing

For this PR, I propose a way of checking return statements that understands cases like above.
The idea is that, for the function above:

functiongetObject<Textendsstring|undefined>(group:T):Textendsstring ?string[] :Textendsundefined ?Record<string,string[]> :never{if(group===undefined){returnrecord;}returnarray;}

when checking the return statementreturn record, TS will know thatgroup has typeundefined. TS will also know that type parameterT corresponds exactly to the type ofgroup. Combining those two pieces of information, TS will know that, inside that branch, the expected return type has to beRecord<string, string[]> (or a supertype). Then, instead of checkingreturn record's type againstT extends string ? string[] : T extends undefined ? Record<string, string[]> : never, it will checkreturn record's type against theRecord<string, string[]> branch of the conditional, i.e. a narrowed version of the conditional type. Then there will be no error on the return statement. In the same manner, when checking the return statementreturn array, TS will know thatgroup has typestring, and that therefore it can check the type of the return statement against thestring[] branch of the conditional return type.

For now, we can think of it like this: when we check return statementreturn record, we see thatgroup has narrowed typeundefined. Then, we plug that information back into the return type by instantiatingT extends string ? string[] : T extends undefined ? Record<string, string[]> : never withT replaced byundefined.

Restrictions

Conditional types

Reasoning about conditional types is pretty tricky. In general, given a functionf(...args): SomeConditionalType whose return type is some (generic) conditional type, we are not able to do the special check proposed above, because it wouldn't be safe.
We need to place some restrictions on what the conditional return type looks like in order for TS to safely analyze it.

We can safely analyze a conditional return type that has the shapeT extends A ? AType : T extends B ? BType : never.
This means the conditional type needs to be distributive (i.e. its check type is a naked type parameterT) and havenever as its false-most type, and it cannot haveinfer type parameters (e.g. it cannot beT extends [infer A] ? AType : T extends B ? BType : never).

Intuitively, we can think of this conditional type shape as reflecting the kind of code one would write in the implementation of such a function.

In addition to the previous restrictions, the type parameter constraint has to be a union type, and the extends types of the conditional (A andB above) have to be constituents of the type parameter's union constraint (T above), like so:

functionfun<TextendsA|B>(param:T):TextendsA ?AType :TextendsB ?BType :never{if(isA(param)){ ...}else{ ...}}

This is because, to narrow the return type, we first need to narrow the type ofparam (more on that below). When we narrow the type ofparam, in a lot of scenarios, we will start from its type,T, or in this case its type constraint,A | B. Then, we will further narrow that type based on information from control flow analysis, e.g. to pick eitherA orB (seegetNarrowableTypeForReference inchecker.ts).

Therefore, in this typical case, narrowingparam means we will end up with a type that is eitherA,B, or a subtype of those. In turn, when we plug this narrowed type back into the conditional return type, this means we will be able to pick a branch of the conditional type and resolve it. e.g. if the narrowed type ofparam isA, the conditional type will resolve toAType.

These additional restrictions are a heuristic meant to capture the "happy path" of narrowing in TS. For instance, if the type parameter's constraint is not a union, then we might have a case like the below:

functionbad<Textendsunknown>(x:T):void{if(x!=undefined){consty:{}=x;}else{consty:null|undefined=x;// Error: `x` is not narrowed here}}functiongood<Textends{}|null|undefined>(x:T):void{if(x!=undefined){consty:{}=x;}else{consty:null|undefined=x;// Works: `x` is narrowed here}}

(Noteunknown is conceptually equivalent to{} | null | undefined, but writingTs constraint as a union instead ofunknown makes narrowing work.)

Aside: whynever

A common way of trying to write a conditional return type is like the following:

functionstringOrNumber<Textendsstring|number>(param:T):Textendsstring ?string :number{if(typeofparam==="string"){return"some string";}return123;}constnum=stringOrNumber(123);conststr=stringOrNumber("string");declareletstrOrNum:string|number;constboth=stringOrNumber(strOrNum);

This example works fine and it would be safe for TS to allow that function implementation. However, in general, it is not safe to allow this pattern of conditional return type. Consider this case:

functionaStringOrANumber<Textends{a:string}|{a:undefined}>(param:T):Textends{a:string} ?string :number{if(typeofparam.a==="string"){return"some string";}return123;}constaNum=aStringOrANumber({a:undefined});constaStr=aStringOrANumber({a:""});// Bad! Type says `number`, but actually should say `string | number`constaNotBoth=aStringOrANumber({a:strOrUndef});

The problem boils down to the fact that, when a conditional return type resolves to its false branch, we can't know if the check type is related or not to the extends type. For the example above, when we plug in{ a: undefined } forT inT extends { a: string } ? string : number, then we fall into the false branch of the conditional, which is desired because{ a: undefined } does not overlap{ a: string }. However, when we plug in{ a: string | undefined } forT inT extends { a: string } ? string : number, we fall into the false branch of the conditional, but this is not desired because{ a: string | undefined } overlaps{ a: string }, and therefore the return type could actually bestring.

Resolving a conditional type to its false-most branch of a conditional type doesn't provide TS with enough information to safely determine what the return type should be, and because of that, narrowing a conditional return type requires the false-most branch of the conditional to benever.

Type parameter references

As hinted at above, to narrow a conditional return type, we first need to narrow a parameter, and we need to know that the type of that parameter uniquely corresponds to a type parameter.
Revisiting our example:

functiongetObject<Textendsstring|undefined>(group:T):Textendsstring ?string[] :Textendsundefined ?Record<string,string[]> :never{if(group===undefined){returnrecord;}returnarray;}

To narrow the return typeT extends string ? string[] : T extends undefined ? Record<string, string[]> : never, we first narrow the type ofgroup inside theif branch, and then we can use that information to reason about what typeT could be replaced with. This only works because the declared type ofgroup is exactlyT, and also because there are no other parameters that use typeT. So in the following cases, TS would not be able to narrow the return type, because there is no unique parameter to whichT is linked:

functionbadGetObject1<Textendsstring|undefined>(group:T,someOtherParam:T):Textendsstring ?string[] :Textendsundefined ?Record<string,string[]> :never{    ...}functionbadGetObject2<Textendsstring|undefined>(group:T,options:{a:number,b:T}):Textendsstring ?string[] :Textendsundefined ?Record<string,string[]> :never{    ...}

Indexed access types

The reasoning explained above for conditional types applies in a similar manner to indexed access types that look like this:

interfaceF{"t":number,"f":boolean,}functiondepLikeFun<Textends"t"|"f">(str:T):F[T]{if(str==="t"){return1;}else{returntrue;}}depLikeFun("t");// has type numberdepLikeFun("f");// has type boolean

So cases like this, where the return type is an indexed access type with a type parameter index, are also supported by this PR. The thinking is similar: in the code above, when we are in theif (str === "t") { ... } branch, we knowstr has type"t", and we can plug that information back into the return typeF[T] which resolves to typenumber, and similarly for theelse branch.

Implementation

The implementation works roughly like this:
When checking a return statement expression:

• We check if the type of the expression is assignable to the return type. If it is, good, nothing else needs to be done. This makes sure we don't introduce new errors to existing code.
• If the type of the expression is not assignable to the return type, we might need to narrow the return type and check again. We proceed to attempt narrowing the return type.
• We check if the return type has the right shape, i.e. it has a shape of eitherSomeType[T] orT extends A ? AType : T extends B ? BType : never, and what parameters the type parameters are uniquely linked to, among other requirements. If any of those requirements is not met, we don't continue with narrowing.
• For every type parameter that is uniquely linked to a parameter, we obtain its narrowed type.
  • Say we have type parameterT that is uniquely linked to parameterparam. To narrow the return type, we first need to obtain the narrowed type forparam at the return statement position. Because, in the source code, there might not be an occurrence ofparam at the return statement position, we create a synthetic reference toparam at that position and obtain its narrowed type via regular control-flow analysis. We then obtain a narrowed typeN forparam. (If we don't, we'll just ignore that type parameter).
• Once we have the narrowed type for each type parameter, we need to plug that information back into the return type. We do this by instantiating the return type with a substitution type. For instance, if the return type isT extends A ? AType : T extends B ? BType : never,T is linked toparam, andparam has narrowed typeN, we will instantiate the return type withT replaced byT & N (as a substitution type).
• Once we obtain this narrowed return type, we get the type of the return expression, this time contextually checked by the narrowed return type, and then check if this type is assignable to the narrowed return type.

Instantiation

As mentioned above, the process of narrowing a return type is implemented as instantiating that return type with the narrowed type parameters replaced by substitution types. Substitution types can be thought of asT & A, whereT is the base type andA the constraint type. There are a few changes made to instantiation to make this work:

• There is now a new kind of substitution type, indicated by theObjectFlags.IsNarrowingType flag, which corresponds to substitution types created by return type narrowing.
• These narrowing substitution types are handled in a special way by conditional type instantiation functions, i.e.getConditionalTypeInstantiation, andgetConditionalType.
• getConditionalTypeInstantiation is responsible for distributing a conditional type over its check type. When instantiating a distributive conditional type ingetConditionalTypeInstantiation, if the conditional's check type is a substitution type likeT & (A | B), the usual logic would not distribute over this type, because it's a substitution type and not a union type. So, for distribution to happen, we have to take apart theT & (A | B) into(T & A) | (T & B), and distribute over that.
• The other special thing that we have to do ingetConditionalTypeInstantiation is to take the intersection of the distribution result, as opposed to the union. This is because, if we narrow a type parameterT toA | B, and we have a conditional return typeT extends A ? R1 : T extends B ? R2 : T extends C ? R3 : never, then we don't know which branch of the conditional return to pick, if branchT extends A ? R1, or branchT extends B ? R2, so we have to check whether the return expression's type is assignable to both, i.e. assignable toR1 & R2.
• Validating whether the conditional type has the right shape to be narrowed happens on-demand ingetConditionalTypeInstantiation (and also at first as an optimization incheckReturnExpression when we're deciding whether to narrow the return type). This is because, as we instantiate a type, we may produce new conditional types that we need to then decide are safe to narrow or not (seenested types case independentReturnType6.ts test).

Conditional expression checking

To support conditional expression checking in return statements, this PR changes how we check a conditional expression in a return statement. Before this PR, when checking a return statementreturn cond ? exp1 : exp2, we obtain the type of the whole expressioncond ? exp1 : exp2, and then compare that type to the return type. With this PR, we now separately check each branch: we first obtain the type ofexp1, and compare that type to the return type, then obtain the type ofexp2 and compare that type to the return type. This allows us to properly check a conditional expression when return type narrowing is needed.

This a breaking change, and the only change that affects existing code, but this change finds bugs.Analysis of extended tests changes:#56941 (comment).
This change also slightly affects performance because we do more checks.Latest perf results here:#56941 (comment).

Performance results

This feature is opt-in. Currently, virtually no code has functions whose return types are conditional or indexed access types that satisfy the restrictions above, so no code goes down the new code path for narrowing return types. This means for existing code, there's no performance impact from the return type narrowing. The only current performance impact is from the conditional expression checking change (see a version of this PR without the change for conditional expressions:#60268 (comment)).

Assessing the performance of the new code path is tricky, as there are no baselines. The existing alternative to conditional return types is to use overloads. In one scenario I tested, checking a function written with conditional return types with this PR took ~+16% check time compared to the same function using overloads and the main branch. However, that's for checking the function declaration. In a different scenario where I included a lot offunction calls though, the version with conditional return types + this PR took ~-15% compared to overloads + main branch. So I'd say the performance is acceptable, especially considering you get stronger checks when using conditional return types, and also only a small number of functions in a codebase should be written using this feature.

Unsupported things

• Inference:
  TS will not infer a conditional return type or an indexed access type for any function or expression. Inferring such a type is more complicated than checking, and inferring such a type could also be surprising for users. This is out of scope.

• Contextually-typed anonymous functions:

typeGetObjectCallback=<Textendsstring|undefined>(group:T)=>Textendsstring ?string[] :Textendsundefined ?Record<string,string[]> :never;constgetObjectBad1:GetObjectCallback=(group)=>{returngroup===undefined ?record :array};// ErrordeclarefunctionouterFun(callback:GetObjectCallback);outerFun((group)=>{returngroup===undefined ?record :array});// Error

This is because, if your function does not have an explicitly annotated return type, we will infer one from the returns.

• Detection of link between parameter and type parameter in more complicated scenarios:

// All cases below are not recognized// Type aliastypeId<X>=X;functionf2<Textendsboolean>(arg:Id<T>):Textendstrue ?string :Textendsfalse ?number :never{if(arg){return"someString";}return123;}// Property typefunctionf3<Textendsboolean>(arg:{prop:T}):Textendstrue ?string :Textendsfalse ?number :never{if(arg.prop){return"someString";}return123;}// Destructuringfunctionf4<Textendsboolean>({ arg}:{arg:T}):Textendstrue ?string :Textendsfalse ?number :never{if(arg.prop){return"someString";}return123;}// Combinations of the above, e.g.:typeOpts<X>={prop:X};functionf5<Textendsboolean>(arg:Opts<T>):Textendstrue ?string :Textendsfalse ?number :never{if(arg.prop){return"someString";}return123;}

This could be supported in the future.