Simplify isDistributionDependent to only check dependance within trueType/falseType

[Andarist]

While looking into #52021 I noticed that isDistributionDependent checks more than if a type parameter is referenced by the conditional's type trueType/falseType. What has been checked is mentioned in this comment (and in the implementation following this comment).

I might be missing something but it seems to me that the only relevant parts of this check should be the trueType and falseType. Tests pass - so that's a good sign as well 😉

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[Andarist]

The new logic more closely matches the comment at the only call site of isDistributionDependent:

// We check for a relationship to a conditional type target only when the conditional type has no
// 'infer' positions and is not distributive or is distributive but doesn't reference the check type
// parameter in either of the result types.

[ahejlsberg]

I don't think we need this change. The additional check mentioned in the comment doesn't come into play in the isDistributionDependent scenario because there are never any intervening statement blocks between the infer declarations and the true and false branches of the conditional type. So we're doing a little bit of (harmless) extra work, but that's all.

[Andarist]

@ahejlsberg when investigating the referenced issue , I noticed that this conditional type is actually determined to be distribution dependent and that surprised me:

function test<T extends {}>() {
    type T1 = T extends {} ? true : false;
}

The change in this PR actually changes the behavior, it's not only an "optimization". I'm not sure how to write a test case that would actually showcase this change though - the case showed in the referenced issue doesn't pass even with this change (just for other reasons, I described the overall issue in more detail here).

So let's take a look at what happens in isTypeParameterPossiblyReferenced for this very case:

node // true
container // function test<T extends {}>() { type T1 = T extends {} ? true : false; }
n // (1st iter): true
n // (2nd iter): T extends {} ? true : false
n // (3rd iter): type T1 = T extends {} ? true : false;
n // (4th iter): { type T1 = T extends {} ? true : false; }

So we return true from isTypeParameterPossiblyReferenced as we encountered a block - a block that is the function's body.

[Andarist]

@sandersn I think this has the wrong status assigned to it right now. It should have "waiting on reviewers" and not "waiting on author".

[sandersn]

@ahejlsberg Mind giving a second opinion based on @Andarist 's explanation?

[sandersn]

It's been a couple of years and this hasn't been high enough priority to reconsider, so I think it's better to close the PR. We can re-open it later (or rewrite it in Go even later) if needed.