Intellisense: support filtering out options with invalid this param constraints

[mjvmroz]

Suggestion

this-param constraints are super useful for providing extensions to generic structures under certain conditions informed by type parameters.

type Result<A> =
  | { type: "ok"; value: A }
  | { type: "ko"; message: string }

abstract class List<out A> {
  abstract reduce<R>(id: R, f: (acc: R, cur: A) => R): R;

  abstract sequenceResult<T>(this: List<Result<T>>): Result<List<T>>;
}

function example(notResults: List<number>, results: List<Result<number>>): void {
  // `sequenceResult` can't be called on `notResults`, but IntelliSense still suggests it.
  // @ts-expect-error
  const notPossible = notResults.sequenceResult();
  
  const possible: Result<List<number>> = results.sequenceResult();
}

Playground

In C# and Kotlin this kind of thing can be accomplished with extension functions. In Rust, Scala and Haskell, there are traits, implicit conversions and typeclasses. I understand that Typescript itself can't support extension functions in this way for a few reasons, so I understand that there's a cap on flexibility here, but by having an option for Intellisense to filter out functions not compatible with the bound this parameter, things would at least be improved for library authors, as highly general libraries could improve their ergonomics without generating an unusably massive search space for users.

🔍 Search Terms

class generic type this parameter constraint intellisense tsserver

✅ 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.

📃 Motivating Example

I'm working on a fairly abstract library for representing data dependencies as a lazily evaluated graph. Where graph nodes contain functions, I'd like to be able to offer invoke extensions to work on the inner function easily. For inner arrays, I'd like to do the same kind of thing, and so on. Monad transformer type stuff, but in a more familiar style to most developers.

One option here today is just to have top-level classes like FunctionNode and ArrayNode, and permit those names to leak into userland. That's not entirely unacceptable, but it's not ideal, and Typescript has this fantastic this-param constraint feature which is perfect. Except that if I want to offer a meaningful volume of these functions, they pollute the IntelliSense search space for users at all times, not just when they apply.

💻 Use Cases

I see this change being helpful to authors of similar libraries, especially in the reactive programming domain.

[RyanCavanaugh]

We tried this, and it had catastrophic performance implications in very common scenarios. See #31377

[jcalz]

Ah, so this is a duplicate-ish of #20608. Sad that it hurts performance.

[mjvmroz]

Ah, that's a shame. :(
Thanks for the reply and the link.