Docs: documented use of function return type conditional on argument type is impractical

[msbit]

Page URL:

https://www.typescriptlang.org/docs/handbook/2/conditional-types.html

Issue:

The example showing use of return type conditional on argument type near

TypeScript-Website/packages/documentation/copy/en/handbook-v2/Type Manipulation/Conditional Types.md

Line 82 in 3cb94f4

We can then use that conditional type to simplify our overloads down to a single function with no overloads.

will compile, but as indicated by the trajectory of microsoft/TypeScript#24929 a type safe function body is not possible.

Recommended Fix:

I can see a few options, either:

• provide a type safe implementation (which is seemingly not possible)
• provide an implementation with one of the unsafe workarounds (returning as any, reinstating the overloads, possibly others)
• remove the specific use of conditional types as a return type dependent on an argument type (preferably with a specific call out that this is not supported, for those who go looking)

[edokeh]

+1

spent much time on this impossible function body

[orta]

Yeah, makes sense, we should probably swap it out with:

```ts twoslash
interface IdLabel {
  id: number /* some fields */;
}
interface NameLabel {
  name: string /* other fields */;
}
type NameOrId<T extends number | string> = T extends number
  ? IdLabel
  : NameLabel;
// ---cut---
function createLabel<T extends number | string>(idOrName: T): NameOrId<T> {
  if (typeof idOrName === "number" ) {
    return { id: idOrName } as NameOrId<T>
  } else {
    return { name: idOrName } as NameOrId<T>
  }
}

let a = createLabel("typescript");
//  ^?

let b = createLabel(2.8);
//  ^?

let c = createLabel(Math.random() ? "hello" : 42);
//  ^?
```

[whschultz]

Yeah, makes sense, we should probably swap it out with:

interface IdLabel {
  id: number /* some fields */;
}
interface NameLabel {
  name: string /* other fields */;
}
type NameOrId<T extends number | string> = T extends number
  ? IdLabel
  : NameLabel;
// ---cut---
function createLabel<T extends number | string>(idOrName: T): NameOrId<T> {
  if (typeof idOrName === "number" ) {
    return { id: idOrName } as NameOrId<T>
  } else {
    return { name: idOrName } as NameOrId<T>
  }
}

let a = createLabel("typescript");
//  ^?

let b = createLabel(2.8);
//  ^?

let c = createLabel(Math.random() ? "hello" : 42);
//  ^?

I find the following works just fine:

interface IdLabel {
    id: number /* some fields */;
}
interface NameLabel {
    name: string /* other fields */;
}

// If you pass a number, you get `IdLabel`
function createLabel(idOrName: number): IdLabel;
// If you pass a string, you get `NameLabel`
function createLabel(idOrName: string): NameLabel;
// If you pass an ambiguous type, you get an ambiguous type.
// Yes, this extra overload needs to be here, if you intend to be
// able to call it this way.  Otherwise, the implementation signature
// isn't externally visible.
function createLabel(idOrName: number | string): IdLabel | NameLabel;

// The implementation has to be able to handle all of the above
// defined possibilities.
function createLabel(idOrName: number | string): IdLabel | NameLabel {
    if (typeof idOrName === "number") {
        return { id: idOrName };
    } else {
        return { name: idOrName };
    }
}

const a: NameLabel = createLabel("typescript");
const b: IdLabel = createLabel(2.8);
const c: NameLabel | IdLabel = createLabel((Math.random() >= 0.5) ? "hello" : 42);

[wbt]

The prime example given in official example documentation for conditional types is not implementable.
The simplest implementation of that Deferred Conditional Type example is:

const getID = function<T extends boolean>(fancy: T): T extends true ? string : number {
	if(fancy) {
		return 'StringID';
	} else {
		return 5;
	}
};

but that fails to compile, even though on lines 3 and 5 where the error occurs the true/false value of 'fancy' is known at compile-time and that should permit TypeScript to figure out the expected type of the return value.

#24929 remaining closed suggest this won't be fixed and it's a big sore spot when trying to implement something like the example.

[typescript-bot]

Hello! As per #2804, we are automatically closing all open issues. Please see #2804 for a description of what issues and PRs can be accepted going forward.