Allow function and method type definitions to omit parameter names (make TS7051 configurable)

[peey]

Suggestion

🔍 Search Terms

TS7051, nameless parameters

✅ 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

The following type definitions should be legal

interface I {
  m(A, B) : C;
}

type Func = (A, B) => C;

Because

1. The names sometimes do not serve a purpose and just add to verbosity (see motivating examples below)
2. The names are not used by the typescript compiler for either type checking or code generation

So parameter names should be treated just as documentation, and like all documentation, it should be optional (forcing documentation where it doesn't fit / isn't needed can add noise!).

📃 Motivating Example

Consider the very simple case type BinaryOperator = (int, int) => int.

It's clearer on its own and any names for the parameters (operand1, operand2 or a, b or x, y, or left, right) would clearly be redundant or feel forced.

One real-life example is present at https://stackoverflow.com/q/42322251/1412255

💻 Use Cases

What do you want to use this for?

I want to use this while designing interfaces.

What shortcomings exist with current approaches?

Forcing unnecessary name adds clutter to the process, or using sensible defaults (e.g. parameter named after the type, e.g. a : A) add refactoring / redesigning burden due to increased, manually managed, verbosity.

What workarounds are you using in the meantime?

Giving random, sensible names. It's not that big of a deal, but it's more of a nice-to-have feature rather than if-this-doesnt-get-fixed-all-hell-will-break-lose kind of a feature.

[jcalz]

Duplicate #16334

Also see #13152 and note that this would be a breaking change in existing TS code despite your check in the checkbox above.