Is it intentional that function signatures don't include generic constraints?

[RunDevelopment]

Search terms

function signature, generic constraints, extends

Question

I recently updated to 0.24.1 and noticed this:

I only read the function signature at first and wondered how T["parent"] is valid TS. After all, T could be any type, so there might not be a parent field. Only after looking at the Type Parameters section did I see the constraint.

So I wanted to ask whether this was intentional.

I can see the appeal of saving precious screen space, but generic constraints can be necessary for the signature to make sense.

[Gerrit0]

This is intentional, I'm not sure how much I agree with it though, it was a decision made before I started maintaining typedoc... could argue that if that type is omitted, shouldn't parameters be as well?

[RunDevelopment]

I just thought that this might be a problem for function overloads. What if 2 functions overloads most meaningfully differ in constraints of their type parameters? Example:

function foo<T extends string>(arg: T): `${T}!`;
function foo<T extends number>(arg: T): T;
function foo(arg: string | number): string | number {
	if (typeof arg === "number") {
		return arg
	}
	return arg + "!"
}

const a = foo("abc") // type: "abc!"
const b = foo(42)    // type: 42

If typedoc only displays the following, then it'll be quite confusing to readers.

foo<T>(arg: T): `${T}!`
foo<T>(arg: T): T

Of course, those are edge cases. I don't know whether making them unambiguous is worth the screen space. The type of constraints might be quite long, and signatures can get very long even without them.

[Gerrit0]

I should have made --hideParameterTypesInTitle also change this, repurposing this issue to make that change

[RunDevelopment]

Thank you @Gerrit0!