Nightly bug(?) with infering function generic while being part of intersection

[toodols]

First of all, the title exists for the sake of a title. I don't really know exactly what is wrong with this bug. I came across this while working on something with redux tookit.

Error: Parameter 'state' implicitly has an 'any' type.
Expected: state = WritableDraft<{username: string, isLoggedIn: true, ...}>

I am using the nightly extension and the bug has not occured because of an update to redux toolkit or a change in my code, but has instead been because of typescript versions changing.
The code itself works in typescript 4.7.0 but not in typescript nightly/4.8.0

In order to create a minimum reproducible example, I have tried to simplify it as much as possible, (which was harder than I imagined). The problem is rather weird, there are multiple parts that cause this bug and removing any will fix it. However, the issue remains, version 4.7.0 works while the same on nightly errors.

At this point, I still do not know exactly what the problem is. In fact, it may even be intentional. However, this is something that breaks redux toolkit so I think the matter is something worth taking a look at.

What search terms have I used? None. I don't know how to put this bug into words.

[RyanCavanaugh]

Taking possible red herrings out of the repro:

// @strict: true

declare function createSlice<T>(
    reducers: { [K: string]: (state: string) => void } & { [K in keyof T]: object }
): void;

createSlice(
	{
		f(a) {}
	}
)

a is string in 4.7 and implicit any in 4.8 and I don't see a good reason for that to have changed.

[andrewbranch]

@typescript-bot bisect good v4.7.4 bad main

[typescript-bot]

The change between v4.7.4 and main occurred at 9236e39.

[andrewbranch]

The PR that caused the behavior change was #48668.

Taking a closer look at @RyanCavanaugh’s simplified repro, it’s not so clear to me what the expected behavior really should be. Both before and after #48668, T is inferred from the mapped type to be { f: unknown }, so the instantiated apparent type of reducers is

{ [key: string]: (state: string) => void } & { f: object }

If you wanted to say that the type of the property f of that type was object & ((state: string) => void), I think that would be reasonable, but that doesn’t seem to be how we treat intersections of concrete properties and index signatures. We consistently say the type of property f of this type is just object... except in this repro pre-#48668. It looks to me like the 4.7 behavior is oddly inconsistent. Even quick info has some puzzling results:

If the contextual type of f is object, how can the contextual type of its parameter not be an implicit any?

To be clear, I don’t think the implicit any is desirable per se, but I think it’s consistent with the inference being made and the general behavior of getting types of concrete properties from an object intersected with an index signature. To get rid of the implicit any, I think we’d either need to

1. Infer {} for T
2. Make ({ [k: string]: T } & { p: U })['p'] → T & U

I don’t know what heuristic we could use to decide to do (1)—it seems super sketchy. (2) makes theoretical sense to me but would be a massive break and probably have tons of undesirable follow-on effects (I’m sure there’s an issue open about this).

TLDR, it’s not great that the behavior changed to introduce an error, but I can’t quite figure out why it ever worked before. Is there a logic to the past behavior I’m missing?

[andrewbranch]

A possible rebuttal of my analysis that I thought about but forgot to address: you might say that getting a property of a contextual type is fuzzier and more permissive than getting a property of that same type via something like a property access expression. For example, if I have a union type string | { x: (state: string) => void }:

type T = string | { x: (state: string) => void };
declare let a: T;
a.x; // Error because `x` is not on all constituents of the union

const y: T = {
  // `state: string` - we simply ignored the unuseful constituents when
  // doing the "same" operation on a contextual type
  x(state) {}
}

However, if the only relevant distinction was "getting a property of a contextual type is not the same as getting a property of a type generally," we would expect this to work:

let x: { [key: string]: (state: string) => void } & { f: object } = {
  f: (a) => {} // Error: `a` is implicitly `any`
};

and it does not. There is something different happening not just because there is a contextual type, but because of... well, something else around that mapped type mapping over keyof T.

[RyanCavanaugh]

Andrew and I kicked this around a while and think the right move on this particular repro is Won't Fix. Reasons for this:

• The thing that broke it changes other things in demonstrably good ways
• In the given repro, there's just no reason to write that index signature, since it only presumably subsumes the behavior of the existing typing since all functions are objects (and in cases where this is not the case, the error is correct). The one place it doesn't is symbol keys, and if you write T in (keyof CaseReducers) & symbol]: {}, then the code works as hoped-for
• We don't really know how to fix it

So anyway if you have a repro that falls under both the "intersection is necessary" and "contextual parameter inference would be sound" umbrellas, we can take a look at that in a new issue. Thanks!