Some long function return expressions no longer evaluated in 5.5 about typescript

[DanielRosenwasser]

I think @dragomirtitian mentioned he was looking into this one.

[whzx5byb]

Workaround: just put the extends infer clause before the arrow function type.

export type inferPipe<t, pipe> =
-    pipe extends (In: t) => unknown ? (In: t) => ReturnType<pipe> : never
+    pipe extends (In: t) => unknown ? ReturnType<pipe> extends infer R ? (In: t) => R : never : never


 export type inferPipe2<t, pipe> =
	pipe extends (In: t) => unknown ?
-		(In: t) => ReturnType<pipe> extends infer n extends number ? n
-		: ReturnType<pipe> extends infer s extends string ? s
-		: ReturnType<pipe> extends infer b extends boolean ? b
+               ReturnType<pipe> extends infer n extends number ? (In: t) => n
+	        : ReturnType<pipe> extends infer s extends string ? (In: t) => s
+		: ReturnType<pipe> extends infer b extends boolean ? (In: t) => b
		: never
	:	never

[ssalbdivad]

@whzx5byb From the original post, there is a simpler work around in this case:

The example from the playground can worked around by inferring a variable in the position of unknown to get the return type directly instead of using the ReturnType alias.

It's possible I'll be able to propagate a similar strategy through the multiple layers in which this is occurring in ArkType, but too early to know for sure yet, particularly that it wouldn't interfere with parameter inference at all which can be very sensitive.

Even if I can find a way to work around it, writing things this way is neither natural nor intuitive whereas a more straightforward approach can lead to very bad outcomes.

As I've been working on potential refactors of ArkType to accommodate this, I've frequently seen return expressions like Exclude<number, ArkError | ArkErrors>which trivially evaluate to a simple type (in this case number) but the extra convolution can make them impossible to visually parse as they're composed.

If I understood what @jakebailey mentioned correctly, this is based on the same code that determines what to write to .d.ts files. If that is the case, I'd expect anyone consuming types from a library like this to take a performance hit as well. Even if some of those types are already cached, it doesn't seem feasible to parse and evaluate a long, complex conditional in the same amount of time it would take to parse an evaluated result like number.