I think this is us taking over the type checker's job and I don't think we've ever had similar logic before (probing something's type where there's no expression in code). Do you have a poc that it's doable in the form of a custom rule?

Do you have a poc that it's doable in the form of a custom rule?

Not yet... which is also partially why I hadn't proposed this previously. But, my (optimistic) thinking is that it would be subject to the same or similar detection as detecting The function returns a boolean expression that’s tied to a refinement on the parameter. that will be needed in #9764.

I don't think that this is actually possible to do.
From what I understand it's not possible to ask speculative questions of TS - i.e. we can't ask the question "after this condition, what is the refinement on x?"

Without that power we can't inspect the type in a certain control flow location.

That aside - we'd have to walk TS's control flow graph somehow to "get" the spot immediately before the termination of the branch -- probably doable -- haven't seen TS's control flow APIs though.

Checking if the refined type is exactly (or assignable to) the predicate type is doable now that we have the relationship API.

Though there are a few places that I know I'd immediately disable the rule.
For example we have a few spots that take an object and duck-type it (eg if ('type' in obj)) to call it an AST node because it's a safe assumption.

So, ah, out of scope for us? Close with another rueful wontfix? 😞

Hmm, I get that there may be slightly more control flow analysis to consider, but I'm not quite following why the refinement analysis isn't the same level of difficulty as in #9764. Am I missing something obvious?

If so, totally fine to close!

#9764 has a very slim, controlled scope:

• The function has a single return statement and no implicit returns.
• The function does not mutate its parameter.
• The function returns a boolean expression that’s tied to a refinement on the parameter.

All that rule needs to do is validate that the function adheres to those things and if it does, report.

OTOH This issue is about trying to figure out what the type of the refined parameter is at a given return point so that we can ensure that it's assignable to the defined predicate type.
As I mentioned above -- TS doesn't allow us to speculate -- we can't say "hey TS if we were to check the type of x at this line here, what would its type be?". Instead we would need to manually build logic to track the branches and assignments in the function body so we can track changes to the parameter's type and thus hopefully understand what the type of the parameter should be when we see a return statement.

I do love the idea of the rule but yeah I just don't think it's possible for us to build.
This would be a good request for TS upstream though -- like a strictTypeGuard compiler option.

I feel like we should document some common limitations of typed rules:

• You can't query variables that does not have a reference in the source code at a particular place
• You can't ask TS to redo checking "if the source looks like this instead"
• Anything else?

Right, but, still, how do you plan to solve that for #9764, then? Like, how would you actually determine that this is an inferrable type predicate?

declare function myTypeGuard(x: unknown): x is string | number;

function maybeInferredTypePredicate(x: unknown) {
  return myTypeGuard(x);
}

(to say nothing of this, which, believe it or not, is inferred as a type predicate)

function maybeInferredTypePredicate(x: unknown) {
  const xIsStringOrNumber = myTypeGuard(x);
  return xIsStringOrNumber;
}

(both in playground)

Like, how would you actually determine that this is an inferrable type predicate?

That rule doesn't specifically care about correctness - it just cares about the rules for inferring the predicate.
So in this instance the function passes the rules:

• it has a single return statement with no implicit returns
• it does not mutate any parameters
• the returned value is a refinement of a parameter.

That last dot point is going to be the complicated bit to solve for sure and I doubt we'll be able to handle all the cases. We'll need to build logic that flags things that look like refinements.

In your examples it's easy cos it's a call to an existing predicate which is an obvious refinement.

Again the important distinction is that #9764 won't need to determine the actual types of things - just that it has to walk backwards from the return statement and go "does it look like a refinement of the parameter?"

Gotcha. Well, I shall wontfix it for now.👍

Thanks for talking through this!