satisfies on Function Declarations

#51556

• You can do satisfies on function expressions because you can use them on any expression.

  const f = ((n, s) => 0) satisfies (n: number, s: string) => number;
  
  // workaround, but without contextual typing:
  
  function f(n: number, s: string): number {
  }
  
  f satisfies (n: number, s: string) => number;

• On JSDoc we support full annotation on function declarations.

• This is pretty similar, right?

  • Could imagine a (f :: (x: string) => void) style annotation.

• Okay, where would this go?

  function func(n, s): number /* satisfies SomeType */ {
  }

• Why would you want to satisfies on a function?

  • Contextual typing of parameters, usually.
  • Is this whole-signature annotation?
    • Not exactly, but it gives you the inference.

• Is this sort of useless for --isolatedDeclarations?

  • Yes.

• Do we want a whole-signature annotation for functions?

  • Maybe as?

    function func(n, s): number /* as SomeType */ {
    }

• Really don't like the use of as

• What about : on the binding?

  function (func: SomeType)(n, s) {
  }

  • Ugh. It makes sense, but really doesn't feel right.

  • Also, there's currently no way to write parentheses on any other binding like in let or const.

    const (func: SomeType) = (n, s) => {
    };

• How about :: at the end?

  • function func(n, s): number /* :: SomeType */ { ... }
  • Ehhhh. Ehh?

• Kind of nice that we could bring along a full overload list with an annotation.

  • Okay but what about inferred parameter types in the presence of overloads?
  • Do nothing - same as we do for overloads today.
  • Wait, why do we still do that? We do something more involved for function expressions contextually typed by types with overloads.

    interface MyFunc {
      (n: number, s: string): number;
      (n: string): void;
    }
    
    const myFunc: MyFunc = (n, s) => {}

    • Wait: no we do not?
    • Depends on the arity of the contextually typed function.
      • Why do we need to manually type unified overload signatures? #25352

• Really don't like ::...

• What about a separate leading declaration?

  function func: MyFunc;
  function func(n, s): number {
  }

  • Don't entirely hate it... but it doesn't work well with method declarations for classes and objects.
    • It's ambiguous whether you have a leading annotated method, or just a property declaration.

• Now does this work for generics?

  • [[Maybe come back to this for notes, seemed fine.]]

• So function (func: MyFunc)(n, s): number?

  • Why does it need parens? function func: MyFunc(n, s): number
    • Because it looks like MyFunc is being applied or something, or that it's a cast - just that the parameters are part of MyFunc, not func.
    • Also would be ambiguous with generics.

• Conclusion?

  • All of this feels awful.
  • "Sleep on it?"
    • "Yeah, maybe hibernate until the spring." 🫠
    • "No, really!"

Make Object Type Resolution Idempotent

• Restore idempotency to resolveObjectTypeMembers #64372
• Confusing missing property error in a circular situation #62180

• Problem: when object types inherit from base types, we need to carefully track re-entrance of bases (e.g. types that rely on the new derived types).
  • The problem is that intermediate computed state can be witnessed in the middle of this process instead of catching circular dependencies and reporting an error.
• One change here: reports a stack of types that led to circularity errors.
  • Love this, but do we report in a stable way?
  • We look for 3 occurrences in the stack and we show them in the order they were encountered.
  • But A, B, C ... A, B, C can also look like B, C, A ... B, C, A.
  • So is it possible to hover over a type and get a different error when checking?
  • It feels like you can get a different order, but only from different locations; at which point, it feels like you should always end up with a stable order in the stack for the same location?
    • ...maybe.
  • Also, should make sure that we possibly truncate the types if they're too long.