Probable bug: Functional properties don't get inferred with circular type parameter constraints like `T extends M<T>`

[devanshj]

TypeScript Version:
4.0.2

Search Terms:
Circular type parameter constraint, functional property inference, function parameter inference, function argument inference

Code:

declare const m: <T extends M<T>>(m: T) => T
type M<Self, K = Exclude<keyof Self, "k" | "t">> =
  { a?: number
  , b?: number
  , c?: number
  , d?: number
  , k?: K
  , t?: (k: K) => void
  }

// :)
// Case 1
m({
  a: 1,
  b: 2,
  k: "a"
})

// :)
// Case 2
m({
  a: 1,
  b: "x", // expected error
  k: "c" // expected error
})

// :(
// Case 3
m({ // type parameter becomes `unknown` (probably because t's first parameter is `any` initially kinda?)
  a: 1,
  b: 2,
  k: "a", 
  t: k => {} // k is inferred as `never` (instead of `"a" | "b"`)
})

// :|
// Case 4
m({
  a: 1,
  b: 2,
  k: "a", 
  t: (k: "a" | "b") => {} // have to explicitly type `k` which could have been inferred :(
})

Expected behavior:
The parameter k of t should be inferred as "a" | "b". As property k already gets inferred in Case 1 & 2, so why not the k parameter of t

Actual behavior:
The parameter of t is inferred as never and T in inferred as unknown. I assume first T gets resolved to unknown as t is initially inferred as (k: any) => void which does not satisfy the constraint of m.

Playground

[devanshj]

@jcalz if you could help in anyway it would be great! 🙏🏻

[devanshj]

Workaround:

- declare const m: <T extends M<T>>(m: T) => T
+ declare const m: <T extends M<T>>(m: Identity<T>) => T

+  type Identity<T> =
+    {  [K in keyof T]:
+          IsPlainObject<T[K]> extends true
+            ? Identity<T[K]>
+            : T[K]
+    }
+  
+  type IsPlainObject<T> =
+    T extends object
+      ? T extends (...a: any[]) => any
+        ? false
+        : true
+      : false

* tears of joy *

I'll keep this issue open to know if this is the "official" way to deal with it or not. I mean it kinda makes sense to me why does it work but still.

[devanshj]

FWIW the #44700 variation makes this seem actually a bug

[RyanCavanaugh]

Pasting in that repro for reference

declare const m: <T extends M<T>>(m: T) => T

type M<Self, V = Prop<Self, "v">> =
  { v: V
  , t?: (v: V) => void
  }

type Prop<T, K> = K extends keyof T ? T[K] : "error"

// expected : M<{ v: number, t?: (v: number) => void }>
// actual   : M<unknown>
m({
  v: 1,
  t: k => {}
})

// expected : M<{ v: number }>
// actual   : M<{ v: number }>
m({
  v: 1
})

[RyanCavanaugh]

What you have here is equivalent to the much simpler, and also working,

declare const m: <T>(m: M<T>) => T

type M<T> = {
  v: T
  t?: (v: T) => void
}

// expected : M<{ v: number, t?: (v: number) => void }>
// actual   : M<unknown>
m({
  v: 1,
  t: k => {}
})

// expected : M<{ v: number }>
// actual   : M<{ v: number }>
m({
  v: 1
})

If I had to wager about the confusion, it's that the default for V is not an existential, but rather an actual default that gets instantiated in-place when not specified.

If you have a description of m that can't be typed straightforwardly, I'd be happy to take another look

[devanshj]

First off I was utterly confused because in the code snippet you wrote // actual : M<unknown> instead of // actual : M<{ v: number, t?: (v: number) => void }> xD It's only when I read "and also working" and tried it in the playground, I realized it indeed works.

If you have a description of m that can't be typed straightforwardly, I'd be happy to take another look

First to give you some context - The thing is I'm using these T extends M<T> style types (I call them "Self Reconstructing" types) to do a variety of cool things (like show custom errors) and mainly strongly type xstate in my project called txstate (which will hopefully be merged with xstate itself). Some of these style of types have already landed xstate like here.

Though to give you a concrete problem and as minimal as I offer right now (while I think of a more minimal problem), you can refer this PR (to another xstate-like library called useStateMachine) and precisely this test case. To make it work you'd have to add a phantom property _: null beside the effect property like so...

useStateMachine({
  initial: "a",
  states: {
    a: {
      _: null, // Remove this and the inference stops working
      effect: parameter => {}
    }
  }
})

This same is the problem with xstate too. So it'd be really cool if you can take another look and see if TypeScript can do a better job of inference. Thanks a lot for your time! :)

TLDR: Open this test case. Remove @ts-ignore. Verify if you can see errors. Add a phantom _: null as a sibling property to effect (like shown above). Verify if the error is gone. State machine libraries like xstate and useStateMachine can be only strongly typed with this "non straightforward" way.

cc @davidkpiano @Andarist @cassiozen

[RyanCavanaugh]

Sorry for leaving in the bad comments, good reminder for me for next time 😅

[devanshj]

Still finding a minimal real world repro for the variation where you need a phantom "_", though I have one for the original problem...

Playground

useStateMachine({
  initial: "a",
  context: { foo: 1 },
  states: {
    a: {
      on: {
        X: "b"
      }
    },
    b: {
      effect: p => {
        p.context.foo === 2 
        // @ts-expect-error (expected error for testing)
        p.context.foo === "a" 
        
        p.event.type === "X"
        // @ts-expect-error (expected error for testing)
        p.event.type === "Y"
      }
    }
  }
})

declare const useStateMachine: <D extends Machine<D>>(definition: InferNarrowestObject<D>) => void

type Machine<Self> = 
  { initial: keyof Get<Self, "states">
  , context: Get<Self, "context">
  , states: 
    { [S in keyof Get<Self, "states">]:
        StateNode<Self, Get<Self, ["states", S]>>
    }
  }

type StateNode<Machine, Self, On = Get<Self, "on">> =
  { on?:
    { [E in keyof On]: MachineStateValue<Machine>
    }
  , effect?:
      (parameter:
        { context: MachineContext<Machine>
        , event: MachineEvent<Machine>
        }
      ) => void
  }

type MachineContext<Machine> = Get<Machine, "context">
type MachineStateValue<Machine> = keyof Get<Machine, "states">
type MachineEvent<Machine> =
  { type:
      { [S in keyof Get<Machine, "states">]:
          keyof Get<Machine, ["states", S, "on"]>
      }[keyof Get<Machine, "states">]
  }

type Get<T, P, F = undefined> =
  P extends keyof T
    ? T[P] :
  P extends [] ?
    T extends undefined ? F : T :
  P extends [infer K1, ...infer Kr] ?
    K1 extends keyof T ?
      Get<T[K1], Kr, F> :
    F :
  never

type InferNarrowest<T> =
  T extends any
    ? ( T extends (...a: any[]) => any ? T :
        T extends object ? InferNarrowestObject<T> :
        T
      )
    : never

type InferNarrowestObject<T> =
  { readonly [K in keyof T]: InferNarrowest<T[K]> }

Notice we need InferNarrowestObject<D> workaround (same as the Identity<T> workaround that I mention in a comment above) to make it work. There isn't a straightforward to strongly type this afaict (if one is even successful these libraries have sophisticated requirements than this snippet)

This is the workaround to be clear

- declare const useStateMachine: <D extends Machine<D>>(definition: D) => void
+ declare const useStateMachine: <D extends Machine<D>>(definition: InferNarrowestObject<D>) => void

Also to tell you what I mean by "custom errors" here's a hypothetical example. The requirement is that if the node to which initial points to is final, then such value for initial shouldn't be allowed and an error should be shown why so.
There's a hell lot of things I'm doing with these types that I can keep going, for example for xstate enforcing ids are unique throughout the whole tree.